[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Aug 4 12:00:00 GMT 2014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It looks ok what PRE does (it's not really a partial partial redundancy but
a full redundndancy).
The bug also reproduces with -O2 -ftree-partial-pre. Disabling loop
optimizations and cddce2 hides the bug.
With PPRE enabled CDDCE2 removes the stores to D.46421.diff (again I see
nothing wrong with doing that).
Btw, this all happens in _M_range_initialize. (-fno-strict-aliasing fixes
the bug as well).
Note that I see stores as OffPtrBase to automatic objects:
- MEM[(struct OffPtrBase *)&D.46421].diff = _70;
and loads from OffPtr via this:
_16 = &MEM[(struct OffPtr *)this_4(D)].D.43564;
or remaining stores:
MEM[(struct OffPtrBase *)this_4(D) + 16B].diff = iftmp.15_41;
I also see:
_74 = (sizetype) _47;
iftmp.10_75 = &D.46429.D.43564 + _74;
__last.3_77 = (long int) iftmp.10_75;
__first.4_78 = (long int) &D.46430.D.43564;
_79 = __last.3_77 - __first.4_78;
which effectively subtracts two unrelated addresses of automatic objects
(boooo - undefined behavior!)
I think the testcase is simply bogus. Can you explain what the "fancy"
pointers
do? Disabling points-to analysis also "fixes" the testcase.
Note that with points-to analysis you cannot reach any other object
with offsetting the address of an object.
More information about the Gcc-bugs
mailing list