https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 17 Jan 2020, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 > > --- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #14) > > Testcase from PR81028 > > > > extern void abort(); > > > > typedef int A; > > typedef float B; > > > > void __attribute__((noinline,noclone)) > > foo(A *p, B *q, long unk) > > { > > for (long i = 0; i < unk; ++i) { > > *p = 1; > > q[i] = 42; > > } > > } > > > > I don't see how the above function cannot be optimized to what we currently > optimize it to? The C/C++ aliasing rules say p and q cannot be a related > pointer at all. > > In the inplacement new case, there is another issue going on. Locals and > changing types was a defect report against C++ (or at least I thought I saw > one). This is about "placement new" or rather the middle-end memory model. You can also simply make p/q point to different union members of the same union where then the above is still valid with unk == 0 but we mess it up, re-ordering the stores (basically we say the stores don't conflict which is not correct for WAW or WAR dependences)
