[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Invalid.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-04 Component|c++ |tree-optimization Version|unknown |4.9.1 Ever confirmed|0 |1 Known to fail||4.10.0, 4.8.2, 4.9.1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. compile with -std=c++11 I can't tell whether it's a regression without rewriting some of the code to avoid features that aren't supported prior to 4.8
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- There is only a single extra PRE performed by partial-PRE. I'll have a look.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
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 (b - 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.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #4 from Thomas Köppe tkoeppe at google dot com --- Ah, you're right, this offset pointer computation as it stands is undefined behaviour. The intended use is to use those pointers only within a preallocated arena, so that the pointers would indeed live in a common object (a large array). I shall change the allocator to an arena allocator and rerun the test. The intended use for offset pointers is to inter-process communication; a vector with the fancy-pointer allocator can be used from two separate processes.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Btw, points-to handles this conservatively, so -fno-tree-pta isn't a real fix either. We didn't yet spot the real bogus transform. But indeed makes sure you are computing differences within one arena only.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #6 from Thomas Köppe tkoeppe at google dot com --- Created attachment 33236 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33236action=edit Fixed demo that doesn't have UB on account of invalid pointer arithmetic Here's a (very lazily) fixed version of the code that allocates from an arena that is a single, large array. The same problem persists in both GCC and Clang.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Smells like a duplicate of PR49330 - still always returning 1 from base_alias_check doesn't fix the original testcase. Which also fails with -O -ftree-pre -ftree-partial-pre -fstrict-aliasing btw.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- The fixed demog works for me (GCC 4.9 and 4.8 at least).
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #9 from Thomas Köppe tkoeppe at google dot com --- Argh, yes, I compiled the wrong file... indeed, the arena version works with GCC 4.8.2 for me, too, and in Clang as well. So... not an issue, I suppose? The desired real application will be for containers allocated in shared memory, which is presumably obtained from some opaque system feature.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 4 Aug 2014, tkoeppe at google dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #9 from Thomas Köppe tkoeppe at google dot com --- Argh, yes, I compiled the wrong file... indeed, the arena version works with GCC 4.8.2 for me, too, and in Clang as well. So... not an issue, I suppose? I think the issue only triggers when you end up using automatic variables for the difference computation.
[Bug tree-optimization/62006] Bad code generation with -O3 (possibly due to -ftree-partial-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62006 --- Comment #11 from Thomas Köppe tkoeppe at google dot com --- Created attachment 33240 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33240action=edit Further fixing: Uses uintptr_ts for the difference On Jonathan's suggestion I changed the distance computation to go through a uintptr_t conversion. Jonathan suggested compiling with -fno-elide-constructors, and indeed the attached code breaks when that option is passed. As you said, the UB caused by the distance computations of automatic objects seems to be the stumbling point.
