* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
@ 2023-07-18 19:29 ` pinskia at gcc dot gnu.org
2023-07-18 19:29 ` pinskia at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this will be fixed with -momit-leaf-frame-pointer patch at :
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624752.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
2023-07-18 19:29 ` [Bug middle-end/110726] " pinskia at gcc dot gnu.org
@ 2023-07-18 19:29 ` pinskia at gcc dot gnu.org
2023-07-18 19:32 ` pinskia at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Whoops wrong bug report.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
2023-07-18 19:29 ` [Bug middle-end/110726] " pinskia at gcc dot gnu.org
2023-07-18 19:29 ` pinskia at gcc dot gnu.org
@ 2023-07-18 19:32 ` pinskia at gcc dot gnu.org
2023-07-18 19:36 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Target Milestone|--- |14.0
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (2 preceding siblings ...)
2023-07-18 19:32 ` pinskia at gcc dot gnu.org
@ 2023-07-18 19:36 ` pinskia at gcc dot gnu.org
2023-07-18 19:36 ` pinskia at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-07-18
Status|UNCONFIRMED |NEW
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It worked at r14-2547-g71a907abdb4c03d4a3419190d .
Mine, looks like r14-2556-g0407ae8a7732d9 caused it ...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (3 preceding siblings ...)
2023-07-18 19:36 ` pinskia at gcc dot gnu.org
@ 2023-07-18 19:36 ` pinskia at gcc dot gnu.org
2023-07-18 19:39 ` pinskia at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (4 preceding siblings ...)
2023-07-18 19:36 ` pinskia at gcc dot gnu.org
@ 2023-07-18 19:39 ` pinskia at gcc dot gnu.org
2023-07-18 20:04 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 19:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
/* a | (a == b) --> a | (b^1) (boolean version of the above). */
(simplify
(bit_ior:c @0 (nop_convert? (eq:c @0 @1)))
(bit_ior @0 (bit_xor @1 { build_one_cst (type); })))
So I guess the issue is eq on generic has an integer type rather than boolean
type ...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (5 preceding siblings ...)
2023-07-18 19:39 ` pinskia at gcc dot gnu.org
@ 2023-07-18 20:04 ` pinskia at gcc dot gnu.org
2023-07-18 20:31 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 20:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 55575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55575&action=edit
Patch which should fix this
So I didn't realize I need the check for "INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& TYPE_PRECISION (TREE_TYPE (@0)) == 1" On these.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (6 preceding siblings ...)
2023-07-18 20:04 ` pinskia at gcc dot gnu.org
@ 2023-07-18 20:31 ` pinskia at gcc dot gnu.org
2023-07-18 21:37 ` slyfox at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 20:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 55576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55576&action=edit
Full testcase
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (7 preceding siblings ...)
2023-07-18 20:31 ` pinskia at gcc dot gnu.org
@ 2023-07-18 21:37 ` slyfox at gcc dot gnu.org
2023-07-18 21:42 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: slyfox at gcc dot gnu.org @ 2023-07-18 21:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #7 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Silly question: I would expect -O0 not to perform any simplifications like
that. Does `gcc` have a knob to disable `match.pd` templates? Or some of them
are crucial for correctness?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (8 preceding siblings ...)
2023-07-18 21:37 ` slyfox at gcc dot gnu.org
@ 2023-07-18 21:42 ` pinskia at gcc dot gnu.org
2023-07-19 2:02 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-18 21:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #7)
> Silly question: I would expect -O0 not to perform any simplifications like
> that. Does `gcc` have a knob to disable `match.pd` templates? Or some of
> them are crucial for correctness?
Some are crucial for correctness usually dealing with c++. you could always use
dbg_cnt to try to narrow down which one is failing.
See
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dbgcnt.def;h=9e2f1d857b49c6c331cc7d1c419eafa0f2403e96;hb=HEAD
For on how to use dbg_cnt
match is the counter here.
Also for generic folding -fdump-tree-original-folding will have the debug info
on what match pattern was applied during "fold" (of generic).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (9 preceding siblings ...)
2023-07-18 21:42 ` pinskia at gcc dot gnu.org
@ 2023-07-19 2:02 ` pinskia at gcc dot gnu.org
2023-07-19 6:13 ` slyfox at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-19 2:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
URL| |https://gcc.gnu.org/piperma
| |il/gcc-patches/2023-July/62
| |4847.html
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624847.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (10 preceding siblings ...)
2023-07-19 2:02 ` pinskia at gcc dot gnu.org
@ 2023-07-19 6:13 ` slyfox at gcc dot gnu.org
2023-07-19 16:16 ` cvs-commit at gcc dot gnu.org
2023-07-19 16:17 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: slyfox at gcc dot gnu.org @ 2023-07-19 6:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #10 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 55575 [details]
> Patch which should fix this
This fixed llvm-16 test suite for me. Thank you!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (11 preceding siblings ...)
2023-07-19 6:13 ` slyfox at gcc dot gnu.org
@ 2023-07-19 16:16 ` cvs-commit at gcc dot gnu.org
2023-07-19 16:17 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-07-19 16:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:
https://gcc.gnu.org/g:bf20b770d9aabb15faf2644b5e3106249cb175f3
commit r14-2648-gbf20b770d9aabb15faf2644b5e3106249cb175f3
Author: Andrew Pinski <apinski@marvell.com>
Date: Tue Jul 18 21:11:46 2023 +0000
Fix PR110726: a | (a == b) can sometimes produce wrong code
So I had missed/forgot that EQ_EXPR could have an non boolean
type for generic when I implemented r14-2556-g0407ae8a7732d9.
This patch adds check for one bit precision intergal type
which fixes the problem.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/110726
gcc/ChangeLog:
* match.pd ((a|b)&(a==b),a|(a==b),(a&b)|(a==b)):
Add checks to make sure the type was one bit precision
intergal type.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/bitops-1.c: New test.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'
2023-07-18 19:09 [Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0' slyfox at gcc dot gnu.org
` (12 preceding siblings ...)
2023-07-19 16:16 ` cvs-commit at gcc dot gnu.org
@ 2023-07-19 16:17 ` pinskia at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-19 16:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 15+ messages in thread