* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
@ 2021-11-03 14:18 ` marxin at gcc dot gnu.org
2021-11-03 14:28 ` marxin at gcc dot gnu.org
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-03 14:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Blocks| |26163
Last reconfirmed| |2021-11-03
Priority|P3 |P1
Ever confirmed|0 |1
Target Milestone|--- |12.0
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
2021-11-03 14:18 ` [Bug tree-optimization/103061] " marxin at gcc dot gnu.org
@ 2021-11-03 14:28 ` marxin at gcc dot gnu.org
2021-11-03 14:34 ` marxin at gcc dot gnu.org
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-03 14:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
The following file is miscompiled:
gfortran -c -o m_MergeSorts.fppized.o -I. -Iinclude -Inetcdf/include -O2
-march=native -g -std=legacy m_MergeSorts.fppized.f90
where first bad debug counter value is:
-fdbg-cnt=back_threadfull2:6
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
2021-11-03 14:18 ` [Bug tree-optimization/103061] " marxin at gcc dot gnu.org
2021-11-03 14:28 ` marxin at gcc dot gnu.org
@ 2021-11-03 14:34 ` marxin at gcc dot gnu.org
2021-11-04 20:44 ` seurer at gcc dot gnu.org
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-03 14:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
There's dump file diff (search for 'dbgcnt'):
https://gist.github.com/marxin/7eadc43d12fdefac6f5b8151a47a8684
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2021-11-03 14:34 ` marxin at gcc dot gnu.org
@ 2021-11-04 20:44 ` seurer at gcc dot gnu.org
2021-11-05 11:47 ` aldyh at gcc dot gnu.org
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-11-04 20:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
seurer at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |seurer at gcc dot gnu.org
--- Comment #3 from seurer at gcc dot gnu.org ---
FWIW I see this on powerpc64 as well.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2021-11-04 20:44 ` seurer at gcc dot gnu.org
@ 2021-11-05 11:47 ` aldyh at gcc dot gnu.org
2021-11-05 11:51 ` aldyh at gcc dot gnu.org
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 11:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> The following file is miscompiled:
>
> gfortran -c -o m_MergeSorts.fppized.o -I. -Iinclude -Inetcdf/include -O2
> -march=native -g -std=legacy m_MergeSorts.fppized.f90
>
> where first bad debug counter value is:
>
> -fdbg-cnt=back_threadfull2:6
This has been a godsend. Thanks!
I added -fdump-tree-threadfull2-details-threading to see the threader in
action. Curiously, it's the same thread over and over, but I do see there
various functions with the same IL (rsort, isort, etc):
$ grep Registering.jump *full2
[7] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
[14] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
[21] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
[28] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
[36] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
[44] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
I guess it doesn't matter which registered thread we look at, since they're all
the same:
[7] Registering jump thread: (41, 20) incoming edge; (20, 21) nocopy;
The screen full immediately before the above message has the path solver in
action:
*********** path_range_query ******************
path_range_query: compute_ranges for path: BB 41, BB 20
from bb20: Registering killing_def (path_oracle) lb_75
Registering value_relation (path_oracle) (_134 == lb_75) (bb41)
Registering value_relation (_134 > M.10_120) (bb35) at _134 = M.10_120 + 1;
Intersecting with existing (_134 > M.10_120) to produce (_134 > M.10_120)
...
...
...
The threaded path is 41->20->21 and the conditional in question is at the end
of BB20:
=========== BB 20 ============
Imports: mstep_49 _71 lb_75
Exports: mstep_49 _71 lb_75 _117 _118 _119 M.10_120
_117 : mstep_49(I) lb_75(I)
_118 : mstep_49(I) lb_75(I) _117
_119 : mstep_49(I) lb_75(I) _117 _118
M.10_120 : mstep_49(I) _71(I) lb_75(I) _117 _118 _119
_22 void * [1B, +INF]
mstep_49 integer(kind=4) [1, 2147483646]
_71 integer(kind=4) [2, +INF]
lstep_114 integer(kind=4) [2, +INF]
Relational : (_117 > lb_75)
Relational : (_117 > mstep_49)
Relational : (_119 > _118)
Relational : (_119 > mstep_49)
Relational : (_118 < _117)
<bb 20> [local count: 56063503181]:
# lb_75 = PHI <_134(41), 1(18)>
_117 = mstep_49 + lb_75;
_118 = _117 + -1;
_119 = mstep_49 + _118;
M.10_120 = MIN_EXPR <_119, _71>;
if (lb_75 > M.10_120)
goto <bb 21>; [11.00%]
else
goto <bb 22>; [89.00%]
Because of the PHI, lb_75 is known to be _134 coming in from BB41, which the
relation oracle registered:
from bb20: Registering killing_def (path_oracle) lb_75
Registering value_relation (path_oracle) (_134 == lb_75) (bb41)
The relation oracle also noted that _134 > M.10_120:
Registering value_relation (_134 > M.10_120) (bb35) at _134 = M.10_120 + 1;
So we can conclude that lb_75 > M.10_120 and thread the path.
This assumes that _134 = M.10_120 + 1 does not overflow. These are
integer(kind=4) types in Fortran. Is this a correct assumption?
That is, is signed overflow undefined in overflow? Can we assume _134 >
M.10_120? If so, then the threading is correct. If not, we need to fix that
relationship :).
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2021-11-05 11:47 ` aldyh at gcc dot gnu.org
@ 2021-11-05 11:51 ` aldyh at gcc dot gnu.org
2021-11-05 11:58 ` marxin at gcc dot gnu.org
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 11:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> That is, is signed overflow undefined in overflow?
Errr, "is signed overflow undefined for integer(kind=4)?"
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2021-11-05 11:51 ` aldyh at gcc dot gnu.org
@ 2021-11-05 11:58 ` marxin at gcc dot gnu.org
2021-11-05 12:02 ` aldyh at gcc dot gnu.org
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-05 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org,
| |burnus at gcc dot gnu.org,
| |pault at gcc dot gnu.org
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
CCing Fortran folks..
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2021-11-05 11:58 ` marxin at gcc dot gnu.org
@ 2021-11-05 12:02 ` aldyh at gcc dot gnu.org
2021-11-05 12:07 ` pinskia at gcc dot gnu.org
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Simplified version without the noise:
<bb 35> [local count: 56063504182]:
_134 = M.10_120 + 1;
if (_71 <= _134)
goto <bb 19>; [11.00%]
else
goto <bb 41>; [89.00%]
...
...
<bb 41> [local count: 49896518755]:
<bb 20> [local count: 56063503181]:
# lb_75 = PHI <_134(41), 1(18)>
_117 = mstep_49 + lb_75;
_118 = _117 + -1;
_119 = mstep_49 + _118;
M.10_120 = MIN_EXPR <_119, _71>;
if (lb_75 > M.10_120)
goto <bb 21>; [11.00%]
else
goto <bb 22>; [89.00%]
If _134 can be assumed to be greater than M.10_120, then we can thread
41->20->21.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2021-11-05 12:02 ` aldyh at gcc dot gnu.org
@ 2021-11-05 12:07 ` pinskia at gcc dot gnu.org
2021-11-05 12:27 ` aldyh at gcc dot gnu.org
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-05 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #5)
> > That is, is signed overflow undefined in overflow?
>
> Errr, "is signed overflow undefined for integer(kind=4)?"
Yes it is undefined. Figures spec would have undefined code in it.
So the question to the reporter is does -fwrapv works for the original
testcase?
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2021-11-05 12:07 ` pinskia at gcc dot gnu.org
@ 2021-11-05 12:27 ` aldyh at gcc dot gnu.org
2021-11-05 12:35 ` marxin at gcc dot gnu.org
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 12:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > > That is, is signed overflow undefined in overflow?
> >
> > Errr, "is signed overflow undefined for integer(kind=4)?"
>
> Yes it is undefined. Figures spec would have undefined code in it.
>
> So the question to the reporter is does -fwrapv works for the original
> testcase?
Ha. Good idea!
The threading still happens with -fwrapv on this testcase:
Registering value_relation (_134 > M.10_120) (bb34) at _134 = M.10_120 + 1;
Is -fwrapv respected by Fortran, cause I'm pretty sure we wouldn't register
that relation if the addition wrapped?
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2021-11-05 12:27 ` aldyh at gcc dot gnu.org
@ 2021-11-05 12:35 ` marxin at gcc dot gnu.org
2021-11-05 12:45 ` marxin at gcc dot gnu.org
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-05 12:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
> So the question to the reporter is does -fwrapv works for the original
> testcase?
So adding -fwrapv does not help, it still crashes.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2021-11-05 12:35 ` marxin at gcc dot gnu.org
@ 2021-11-05 12:45 ` marxin at gcc dot gnu.org
2021-11-05 13:16 ` amacleod at redhat dot com
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-05 12:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
And note that the benchmark survives -fsanitize=undefined run.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2021-11-05 12:45 ` marxin at gcc dot gnu.org
@ 2021-11-05 13:16 ` amacleod at redhat dot com
2021-11-05 13:28 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: amacleod at redhat dot com @ 2021-11-05 13:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> ---
On 11/5/21 8:02 AM, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
>
> --- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Simplified version without the noise:
>
> <bb 35> [local count: 56063504182]:
> _134 = M.10_120 + 1;
> if (_71 <= _134)
> goto <bb 19>; [11.00%]
> else
> goto <bb 41>; [89.00%]
>
> ...
> ...
>
> <bb 41> [local count: 49896518755]:
>
> <bb 20> [local count: 56063503181]:
> # lb_75 = PHI <_134(41), 1(18)>
> _117 = mstep_49 + lb_75;
> _118 = _117 + -1;
> _119 = mstep_49 + _118;
> M.10_120 = MIN_EXPR <_119, _71>;
> if (lb_75 > M.10_120)
> goto <bb 21>; [11.00%]
> else
> goto <bb 22>; [89.00%]
>
> If _134 can be assumed to be greater than M.10_120, then we can thread
> 41->20->21.
>
I dont understand why? isnt m.10_120 killed in bb20? whats the basis
for threading that? I dont see it
layed out, the thread would be:
<bb 35> [local count: 56063504182]:
_134 = M.10_120 + 1;
*relation _71 >_134
<bb 20> [local count: 56063503181]:
lb_75 = _134
_117 = mstep_49 + lb_75; __117 = mstep_49 + _134
_118 = _117 + -1;
_119 = mstep_49 + _118; mstep_49 + mstep_49 + _134 + -1
M.10_120 = MIN_EXPR <_119, _71>; MIN < ^that, _134> kill
m.10_120
if (lb_75 > M.10_120) if (OLD-M.10_120 + 1 > m.10_120)
goto <bb 21>; [11.00%]
else
goto <bb 22>; [89.00%]
I dont see how you can thread to 21?
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2021-11-05 13:16 ` amacleod at redhat dot com
@ 2021-11-05 13:28 ` aldyh at gcc dot gnu.org
2021-11-05 14:44 ` aldyh at gcc dot gnu.org
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 13:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #12)
> I dont understand why? isnt m.10_120 killed in bb20? whats the basis
> for threading that? I dont see it
Huh. The last thing we do in the solver is kill the M.10_120, so it looks like
we're registering things correctly:
*********** path_range_query ******************
path_range_query: compute_ranges for path: BB 41, BB 20
from bb20: Registering killing_def (path_oracle) lb_75
Registering value_relation (path_oracle) (_134 == lb_75) (bb41)
Registering value_relation (_134 > M.10_120) (bb35) at _134 = M.10_120 + 1;
Intersecting with existing (_134 > M.10_120) to produce (_134 > M.10_120)
range_defined_in_block (BB20) for lb_75 is integer(kind=4) [3, 2147483646]
Registering killing_def (path_oracle) _119
Registering killing_def (path_oracle) _118
Registering killing_def (path_oracle) _117
Registering value_relation (path_oracle) (_117 > mstep_49) (bb41)
Registering value_relation (path_oracle) (_117 > lb_75) (bb41)
range_defined_in_block (BB20) for _117 is integer(kind=4) [4, +INF]
Registering value_relation (path_oracle) (_118 < _117) (bb41)
range_defined_in_block (BB20) for _118 is integer(kind=4) [3, 2147483646]
Registering value_relation (path_oracle) (_119 > mstep_49) (bb41)
Registering value_relation (path_oracle) (_119 > _118) (bb41)
range_defined_in_block (BB20) for _119 is integer(kind=4) [4, +INF]
Registering killing_def (path_oracle) M.10_120
<<<KILL KILL
range_defined_in_block (BB20) for M.10_120 is integer(kind=4) [4, +INF]
<<<KILL KILL
path_oracle:
Equivalence set : [M.10_120]
Equivalence set : [_117]
Equivalence set : [_118]
Equivalence set : [_119]
Equivalence set : [lb_75, _134]
Equivalence set : [lb_75]
Relational : (_119 > _118)
Relational : (_119 > mstep_49)
Relational : (_118 < _117)
Relational : (_117 > lb_75)
Relational : (_117 > mstep_49)
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (13 preceding siblings ...)
2021-11-05 13:28 ` aldyh at gcc dot gnu.org
@ 2021-11-05 14:44 ` aldyh at gcc dot gnu.org
2021-11-05 21:39 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
So yeah, we are killing the relation in the *path* oracle:
Registering killing_def (path_oracle) M.10_120
range_defined_in_block (BB20) for M.10_120 is integer(kind=4) [4, +INF]
but the _134 > M.10_120 relation came from the *root* oracle (i.e. outside of
the path). It seems we must keep track of killed names along the path, and
never query the root oracle for those.
So...mine.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (14 preceding siblings ...)
2021-11-05 14:44 ` aldyh at gcc dot gnu.org
@ 2021-11-05 21:39 ` aldyh at gcc dot gnu.org
2021-11-06 8:26 ` marxin at gcc dot gnu.org
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-05 21:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 51740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51740&action=edit
untested patch
This should do it. Martin, can you verify this fixes it on your end?
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (15 preceding siblings ...)
2021-11-05 21:39 ` aldyh at gcc dot gnu.org
@ 2021-11-06 8:26 ` marxin at gcc dot gnu.org
2021-11-06 15:36 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-06 8:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #15)
> Created attachment 51740 [details]
> untested patch
>
> This should do it. Martin, can you verify this fixes it on your end?
Yes, it does! Thanks a lot.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (16 preceding siblings ...)
2021-11-06 8:26 ` marxin at gcc dot gnu.org
@ 2021-11-06 15:36 ` cvs-commit at gcc dot gnu.org
2021-11-06 15:36 ` aldyh at gcc dot gnu.org
2021-12-10 12:04 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-06 15:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:
https://gcc.gnu.org/g:4856699eeb2809c50930bafe341a96470877195d
commit r12-4971-g4856699eeb2809c50930bafe341a96470877195d
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Fri Nov 5 22:25:19 2021 +0100
path oracle: Do not look at root oracle for killed defs.
The problem here is that we are incorrectly threading 41->20->21 here:
<bb 35> [local count: 56063504182]:
_134 = M.10_120 + 1;
if (_71 <= _134)
goto <bb 19>; [11.00%]
else
goto <bb 41>; [89.00%]
...
...
...
<bb 41> [local count: 49896518755]:
<bb 20> [local count: 56063503181]:
# lb_75 = PHI <_134(41), 1(18)>
_117 = mstep_49 + lb_75;
_118 = _117 + -1;
_119 = mstep_49 + _118;
M.10_120 = MIN_EXPR <_119, _71>;
if (lb_75 > M.10_120)
goto <bb 21>; [11.00%]
else
goto <bb 22>; [89.00%]
First, lb_17 == _134 because of the PHI.
Second, _134 > M.10_120 because of _134 = M.10_120 + 1.
We then assume that lb_75 > M.10_120, but this is incorrect because
M.10_120 was killed along the path.
This incorrect thread causes the miscompilation in 527.cam4_r.
Tested on x86-64 and ppc64le Linux.
gcc/ChangeLog:
PR tree-optimization/103061
* value-relation.cc (path_oracle::path_oracle): Initialize
m_killed_defs.
(path_oracle::killing_def): Set m_killed_defs.
(path_oracle::query_relation): Do not look at the root oracle for
killed defs.
* value-relation.h (class path_oracle): Add m_killed_defs.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (17 preceding siblings ...)
2021-11-06 15:36 ` cvs-commit at gcc dot gnu.org
@ 2021-11-06 15:36 ` aldyh at gcc dot gnu.org
2021-12-10 12:04 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-06 15:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4
2021-11-03 14:18 [Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org
` (18 preceding siblings ...)
2021-11-06 15:36 ` aldyh at gcc dot gnu.org
@ 2021-12-10 12:04 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-12-10 12:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:
https://gcc.gnu.org/g:2a1c3b69c015ea49e4c7c08291efd8f7e28e1193
commit r12-5891-g2a1c3b69c015ea49e4c7c08291efd8f7e28e1193
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Fri Dec 10 12:02:04 2021 +0000
PR ipa/103601: ICE compiling CSiBE in ipa-modref's insert_kill.
This patch fixes PR ipa/103061 which is P1 regression that shows up as
an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
benchmark. I believe the underlying cause is that the new kill tracking
functionality wasn't anticipating memory accesses that are zero bits
wide!?. The failing source code (test case) contains the unusual lines:
typedef struct { } spinlock_t;
and
q->lock = (spinlock_t) { };
Making spinlock_t larger, or removing the assignment work around the issue.
The one line patch below to useful_for_kill_p teaches IPA that a memory
write is only useful as a "kill" if it is more than zero bits wide.
In theory, the existing known_size_p (size) test is now redundant, as
poly_int64 currently uses the value -1 for unknown size values,
but the proposed change makes the semantics clear, and defends against
possible future changes in representation.
2021-12-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR ipa/103601
* ipa-modref-tree.h (useful_for_kill_p): Zero width accesses aren't
useful for kill tracking.
gcc/testsuite/ChangeLog
PR ipa/103601
* gcc.dg/ipa/pr103601.c: New test case.
^ permalink raw reply [flat|nested] 21+ messages in thread