[Bug tree-optimization/103061] New: [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[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]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061

            Bug ID: 103061
           Summary: [12 Regression] 527.cam4_r miscompiled with -O2
                    -march=znver1 since r12-4790-g4b3a325f07acebf4
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

Since the revision, the benchmark fails:

527.cam4_r: copy 0 non-zero return code (exit code=139, signal=0)

****************************************
Contents of cam4_r_peak.gcc-m64.err
****************************************
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0  0x7ffff79e279f in ???
        at
/usr/src/debug/glibc-2.34-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#1  0x4cb5a4 in merge_
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:586
#2  0x4cb5a4 in mergesort_
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:562
#3  0x4cb5a4 in __m_mergesorts_MOD_dsort_
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:543
#4  0x4cbee2 in __m_mergesorts_MOD_dsortn_
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/m_MergeSorts.fppized.f90:225
#5  0x4d2cb3 in __phys_grid_MOD_phys_grid_init
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/phys_grid.fppized.f90:399
#6  0x75af58 in __inital_MOD_cam_initial
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/inital.fppized.f90:98
#7  0x7892e2 in __cam_comp_MOD_cam_init
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/cam_comp.fppized.f90:130
#8  0x7a4a2c in __atm_comp_mct_MOD_atm_init_mct
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/atm_comp_mct.fppized.f90:263
#9  0x7ea59d in __ccsm_comp_mod_MOD_ccsm_init
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_comp_mod.fppized.f90:928
#10  0x40379c in ccsm_driver
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_driver.fppized.f90:57
#11  0x40379c in main
        at
/home/marxin/Programming/cpu2017/benchspec/CPU/527.cam4_r/build/build_peak_gcc-m64.0001/ccsm_driver.fppized.f90:25

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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)

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[seurer at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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 :).

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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)?"

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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..

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[pinskia at gcc dot gnu.org]

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?

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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?

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[amacleod at redhat dot com]

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?

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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)

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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?

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[cvs-commit at gcc dot gnu.org]

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.

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org]

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

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[cvs-commit at gcc dot gnu.org]

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.