https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #3) > On Tue, 15 Aug 2023, ppalka at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 > > > > Patrick Palka <ppalka at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |ppalka at gcc dot gnu.org > > Keywords|needs-bisection | > > > > --- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> --- > > Bisection points to r12-4319-g09a0affdb0598a > > Huh, that should make us optimize less ... (it was also backported > to GCC 11). Having a good/bad rev should make it easier to analyze > though - thanks. Indeed it does, optimizing more simply avoids the bug somehow. The bug is that we think this->next is invariant in the loop, thus n->next = nullptr cannot possibly clobber it. LIM2 hoists it out of the loop. The accesses are [t.C:18:18] # PT = nonlocal escaped null { D.43517 D.43765 D.53227 D.53358 D.53446 } (escaped, escaped heap) _77 = [t.C:18:18] __MEM <struct Target> ((struct Target *)_26).D_43475.next; vs. [t.C:27:15] [t.C:27:10] _170->next = _Literal (struct Base *) 0; where _170 is of type (struct Base *). and # PT = nonlocal escaped null { D.43517 D.43765 D.53227 D.53358 D.53446 } (escaped, escaped heap) _170 = __PHI ([t.C:18:18] __BB46: _77, [t.C:18:18] __BB45: _20); -fno-tree-loop-im fixes this at any optimization level.
