* [Bug target/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
@ 2024-07-16 22:15 ` slyfox at gcc dot gnu.org
2024-07-16 22:23 ` [Bug middle-end/115961] " pinskia at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: slyfox at gcc dot gnu.org @ 2024-07-16 22:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #1 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Forgot to post minimized example:
// $ cat a.cc
struct e { unsigned pre : 12; unsigned a : 4; };
static unsigned min_u(unsigned a, unsigned b) { return (b < a) ? b : a; }
__attribute__((noipa))
void bug(e * v, unsigned def, unsigned use) {
e & defE = *v;
defE.a = min_u(use + 1, 0xf);
}
__attribute__((noipa, optimize(0)))
int main(void) {
e v = { 0xded, 3 };
bug(&v, 32, 33);
if (v.a != 0xf) __builtin_trap();
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
2024-07-16 22:15 ` [Bug target/115961] " slyfox at gcc dot gnu.org
@ 2024-07-16 22:23 ` pinskia at gcc dot gnu.org
2024-07-17 2:17 ` [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision pan2.li at intel dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-07-16 22:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-07-16
Target Milestone|--- |15.0
Component|target |middle-end
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The gimple looks semi-correct:
_1 = use_4(D) + 1;
_2 = .SAT_TRUNC (_1);
v_3(D)->a = _2;
From:
e & defE = *v;
defE.a = min_u(use + 1, 0xf);
There is a missing check for type_has_mode_precision_p somewhere.
Either in direct_optab_supported_p or somewhere else.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
2024-07-16 22:15 ` [Bug target/115961] " slyfox at gcc dot gnu.org
2024-07-16 22:23 ` [Bug middle-end/115961] " pinskia at gcc dot gnu.org
@ 2024-07-17 2:17 ` pan2.li at intel dot com
2024-07-17 3:33 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pan2.li at intel dot com @ 2024-07-17 2:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #3 from Li Pan <pan2.li at intel dot com> ---
Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the same
as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863 ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
` (2 preceding siblings ...)
2024-07-17 2:17 ` [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision pan2.li at intel dot com
@ 2024-07-17 3:33 ` pinskia at gcc dot gnu.org
2024-07-17 4:05 ` pan2.li at intel dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-07-17 3:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Li Pan from comment #3)
> Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the
> same as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863 ?
No it is a different issue.
here we have a uint:4; an unsigned integer with 4 bit precision which is not
the same precision as QImode (8bit).
Since the optabs are only mode, we only check the mode of the type which is
QImode but the type has a lower precision than the mode itself.
So we get a SAT_TRUNC which is using the QImode sat_truncate opcode but we
really need 4bit sat_truncate.
This is why I mentioned there is a missing check for type_has_mode_precision_p
here.
type_has_mode_precision_p is defined as:
```
inline bool
type_has_mode_precision_p (const_tree t)
{
return known_eq (TYPE_PRECISION (t), GET_MODE_PRECISION (TYPE_MODE (t)));
}
```
I wonder if we have the same issue with some other direct calls internal
functions too. But I have not looked into others that is accessible except for
__builtin_clzg which always does the right thing.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
` (3 preceding siblings ...)
2024-07-17 3:33 ` pinskia at gcc dot gnu.org
@ 2024-07-17 4:05 ` pan2.li at intel dot com
2024-07-24 4:52 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pan2.li at intel dot com @ 2024-07-17 4:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #5 from Li Pan <pan2.li at intel dot com> ---
Thanks Andrew Pinski.
That make much sense to me, and I can reproduce this from upstream now. Let me
file a patch for it.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
` (4 preceding siblings ...)
2024-07-17 4:05 ` pan2.li at intel dot com
@ 2024-07-24 4:52 ` cvs-commit at gcc dot gnu.org
2024-07-24 15:06 ` pinskia at gcc dot gnu.org
2024-07-25 7:39 ` slyfox at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-07-24 4:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pan Li <panli@gcc.gnu.org>:
https://gcc.gnu.org/g:905973410957891fec8a3e42eeefa4618780e0ce
commit r15-2241-g905973410957891fec8a3e42eeefa4618780e0ce
Author: Pan Li <pan2.li@intel.com>
Date: Thu Jul 18 17:23:36 2024 +0800
Internal-fn: Only allow modes describe types for internal fn[PR115961]
The direct_internal_fn_supported_p has no restrictions for the type
modes. For example the bitfield like below will be recog as .SAT_TRUNC.
struct e
{
unsigned pre : 12;
unsigned a : 4;
};
__attribute__((noipa))
void bug (e * v, unsigned def, unsigned use) {
e & defE = *v;
defE.a = min_u (use + 1, 0xf);
}
This patch would like to add checks for the direct_internal_fn_supported_p,
and only allows the tree types describled by modes.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully regression tests.
PR target/115961
gcc/ChangeLog:
* internal-fn.cc (type_strictly_matches_mode_p): Add new func
impl to check type strictly matches mode or not.
(type_pair_strictly_matches_mode_p): Ditto but for tree type
pair.
(direct_internal_fn_supported_p): Add above check for the tree
type pair.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr115961-run-1.C: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
` (5 preceding siblings ...)
2024-07-24 4:52 ` cvs-commit at gcc dot gnu.org
@ 2024-07-24 15:06 ` pinskia at gcc dot gnu.org
2024-07-25 7:39 ` slyfox at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-07-24 15:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed. The fortran failures from my patches for PR 115086 are also fixed after
this.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision
2024-07-16 22:14 [Bug target/115961] New: [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 slyfox at gcc dot gnu.org
` (6 preceding siblings ...)
2024-07-24 15:06 ` pinskia at gcc dot gnu.org
@ 2024-07-25 7:39 ` slyfox at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: slyfox at gcc dot gnu.org @ 2024-07-25 7:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #8 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
The change also fixes all llvm-18.1.8 testsuite failures for me. Thank you!
^ permalink raw reply [flat|nested] 9+ messages in thread