public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs
@ 2022-03-02 10:37 ro at gcc dot gnu.org
2022-03-02 10:37 ` [Bug tree-optimization/104754] " ro at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: ro at gcc dot gnu.org @ 2022-03-02 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Bug ID: 104754
Summary: gcc.dg/pr102892-1.c FAILs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, hjl.tools at gmail dot com
Target Milestone: ---
Target: sparc*-sun-solaris2.11, mipsel-mti-elf,
s390x-ibm-linux-gnu,hppa2.0w-hp-hpux11.11,
m68k-unknown-linux-gnu
The gcc.dg/pr102892-1.c test FAILs on Solaris/SPARC (32 and 64-bit) since its
introduction:
+FAIL: gcc.dg/pr102892-1.c (test for excess errors)
Excess errors:
Undefined first referenced
symbol in file
foo /var/tmp//ccwHT.Oa.o
According to gcc-testresults, there are quite a number of other targets
affected
as well.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
@ 2022-03-02 10:37 ` ro at gcc dot gnu.org
2022-03-03 18:04 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: ro at gcc dot gnu.org @ 2022-03-02 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |12.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
2022-03-02 10:37 ` [Bug tree-optimization/104754] " ro at gcc dot gnu.org
@ 2022-03-03 18:04 ` aldyh at gcc dot gnu.org
2022-03-03 18:12 ` aldyh at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-03-03 18:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2022-03-03
CC| |amacleod at redhat dot com
--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed on a cross to m68k-unknown-linux-gnu.
Interestingly this may actually be a regression against GCC11, at least on this
target (and possibly the others mentioned though I haven't checked).
The test verifies that there are no calls to foo(). On m68k the gate to foo()
flows through here (threadfull2 dump right before vrp2):
<bb 3> [local count: 715863673]:
# ivtmp.9_23 = PHI <ivtmp.9_24(11), ivtmp.9_7(9)>
bar ();
_2 = (void *) ivtmp.9_23;
_1 = MEM[(long int *)_2];
ivtmp.9_24 = ivtmp.9_23 + 4;
if (_1 == 1)
goto <bb 4>; [20.24%]
else
goto <bb 5>; [79.76%]
<bb 4> [local count: 144890806]:
foo ();
ivtmp.9_24 has been set previously in BB9 to:
ivtmp.9_7 = (unsigned int) &b;
VRP2 can't seem to do anything with the above sequence, since it can't figure
out what _1 is. I suppose it could, since there is enough information to to
get at "b" at -O3.
On x86, where the test passes, we have the following before vrp2:
<bb 3> [local count: 477266310]:
# c_4 = PHI <c_14(7)>
bar ();
_15 = (sizetype) c_4;
_17 = MEM[(long int *)&b + _15 * 8];
if (_17 == 1)
goto <bb 4>; [20.24%]
else
goto <bb 5>; [79.76%]
<bb 4> [local count: 96598701]:
foo ();
c_29 = c_4 + 1;
goto <bb 8>; [100.00%]
which vrp2 can happily optimize to:
<bb 6> [local count: 477266310]:
bar ();
_17 = 0;
if (_17 == 1)
goto <bb 3>; [20.24%]
else
goto <bb 4>; [79.76%]
...
...
<bb 3> [local count: 96598701]:
foo ();
goto <bb 7>; [100.00%]
Thus leading to foo's demise by ccp4.
I haven't dug deep, but this is likely due to the pointer equivalence tracking
we use in evrp/VRP2 not being able to see that this is all funny talk for b[]:
ivtmp.9_7 = (unsigned int) &b;
...
...
# ivtmp.9_23 = PHI <ivtmp.9_24(11), ivtmp.9_7(9)>
_2 = (void *) ivtmp.9_23;
_1 = MEM[(long int *)_2];
if (_1 == 1)
We have plans for a proper pointer range class for GCC13, though I wonder
whether we'll be able to handle the above gymnastics.
FWIW, the above transformation seems to be ivopts at play.
Whereas on x86 we go from:
<bb 3> [local count: 715863673]:
# c_19 = PHI <c_14(12), c_20(10)>
bar ();
_1 = b[c_19][0];
if (_1 == 1)
to:
<bb 3> [local count: 715863673]:
# c_19 = PHI <c_14(12), c_20(10)>
bar ();
_23 = (sizetype) c_19;
_1 = MEM[(long int *)&b + _23 * 8];
if (_1 == 1)
goto <bb 4>; [20.24%]
on m68k we transform the sequence to:
<bb 3> [local count: 715863673]:
# ivtmp.9_23 = PHI <ivtmp.9_24(12), ivtmp.9_7(10)>
bar ();
_2 = (void *) ivtmp.9_23;
_1 = MEM[(long int *)_2];
ivtmp.9_24 = ivtmp.9_23 + 4;
if (_1 == 1)
Perhaps someone with more target-foo can opine.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
2022-03-02 10:37 ` [Bug tree-optimization/104754] " ro at gcc dot gnu.org
2022-03-03 18:04 ` aldyh at gcc dot gnu.org
@ 2022-03-03 18:12 ` aldyh at gcc dot gnu.org
2022-03-04 12:17 ` aldyh at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-03-03 18:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
BTW, on GCC11, ivopts doesn't even get a whack at it. The whole thing is
optimized away by .fre4:
int main ()
{
long int a;
long int c;
<bb 2> [local count: 44232128]:
if (a_9(D) <= 0)
goto <bb 13>; [89.00%]
else
goto <bb 7>; [11.00%]
<bb 13> [local count: 39366592]:
bar ();
bar ();
<bb 7> [local count: 44232131]:
return 0;
}
Perhaps this is a regression elsewhere.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
` (2 preceding siblings ...)
2022-03-03 18:12 ` aldyh at gcc dot gnu.org
@ 2022-03-04 12:17 ` aldyh at gcc dot gnu.org
2022-05-06 8:32 ` jakub at gcc dot gnu.org
2023-05-08 12:24 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-03-04 12:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Upon closer inspection, evrp in GCC11 and mainline are generating slightly
different code which keeps FRE from cleaning this up in mainline.
Mainline is transforming the conditional here:
<bb 8> :
# c_3 = PHI <0(2), c_2(7)>
# a_4 = PHI <a_9(D)(2), a_12(7)>
if (a_4 <= 0)
goto <bb 6>; [INV]
else
goto <bb 9>; [INV]
...into a_4 != 1.
This doesn't make a lot of sense until you realize that the testcase is
invoking undefined behavior. Well, it still doesn't make sense, but "a" is
uninitialized in the test:
for (long a; a < 1; ++a)
We should either initialize a to 0, or remove the test altogether.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
` (3 preceding siblings ...)
2022-03-04 12:17 ` aldyh at gcc dot gnu.org
@ 2022-05-06 8:32 ` jakub at gcc dot gnu.org
2023-05-08 12:24 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-06 8:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.0 |12.2
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
` (4 preceding siblings ...)
2022-05-06 8:32 ` jakub at gcc dot gnu.org
@ 2023-05-08 12:24 ` rguenth at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-08 12:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.3 |12.4
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-05-08 12:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-02 10:37 [Bug tree-optimization/104754] New: gcc.dg/pr102892-1.c FAILs ro at gcc dot gnu.org
2022-03-02 10:37 ` [Bug tree-optimization/104754] " ro at gcc dot gnu.org
2022-03-03 18:04 ` aldyh at gcc dot gnu.org
2022-03-03 18:12 ` aldyh at gcc dot gnu.org
2022-03-04 12:17 ` aldyh at gcc dot gnu.org
2022-05-06 8:32 ` jakub at gcc dot gnu.org
2023-05-08 12:24 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).