https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77745
Bug ID: 77745 Summary: Inconsistent application of aliasing rules Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- For the following C++ testcase: #include <new> long foo(char *c1, char *c2) { long *p1 = new(c1) long; *p1 = 100; long long *p2 = new(c2) long long; *p2 = 200; long *p3 = new(c2) long; *p3 = 200; return *p1; } GCC generates on x86-64: movq $100, (%rdi) movl $100, %eax movq $200, (%rsi) ret i.e. the routine returns 100 unconditionally, regardless of whether c1 and c2 point to the same storage. However, changing '*p3 = 200' to e.g. '*p3 = 300' (another constant), or using a 32-bit target (so the types are no longer same size) suppresses the optimization. Since this source code is either well-defined or not regardless of the last constant value, or "bitness" of the target, there's an internal inconsistency in GCC: either it performed a misoptimization in the above output, or misses the same optimization in other circumstances. I see the propagation happening in fre1 pass. GCC 4.5 didn't perform this transformation, so if it's invalid, that's a regression.