https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Component|tree-optimization |rtl-optimization
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
And it is IVOPTs generating a strange IV:
_44 = (unsigned long) &d;
ivtmp.22_43 = _44 + 19600;
# ivtmp.22_13 = PHI <ivtmp.22_43(9), ivtmp.22_42(7)>
...
_50 = -_44;
MEM[symbol: c, base: _50, index: ivtmp.22_13, offset: -19600B] = 0;
somehow confusing RTL alias analysis. -fno-gcse hides the issue.
We expand this to
;; MEM[symbol: c, base: _50, index: ivtmp.22_13, offset: -19600B] = 0;
(insn 13 12 14 (parallel [
(set (reg:DI 99)
(neg:DI (reg:DI 95 [ _44 ])))
(clobber (reg:CC 17 flags))
]) "t.c":15 -1
(nil))
(insn 14 13 15 (set (reg/f:DI 100)
(const:DI (plus:DI (symbol_ref:DI ("c") [flags 0x2] <var_decl
0x7ff98b1d3b40 c>)
(const_int -19600 [0xffffffffffffb370])))) "t.c":15 -1
(nil))
(insn 15 14 0 (set (mem:SI (plus:DI (plus:DI (reg:DI 99)
(reg:DI 91 [ ivtmp.22 ]))
(const:DI (plus:DI (symbol_ref:DI ("c") [flags 0x2] <var_decl
0x7ff98b1d3b40 c>)
(const_int -19600 [0xffffffffffffb370])))) [2
MEM[symbol: c, base: _50, index: ivtmp.22_13, offset: -19600B]+0 S4 A32])
(const_int 0 [0])) "t.c":15 -1
(nil))
and I can very well imagine we're getting confused by find_base_term
logic here.
There's logic in IVOPTs to not generate IVs based on two different
objects but somehow it doesn't trigger here.
