[Bug tree-optimization/69776] [4.9/5 Regression] Wrong optimization with aliasing

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776

--- Comment #8 from Alexander Cherepanov <ch3root at openwall dot com> ---
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Actually the middle-end memory model makes this valid and FREs redundant store
> elimination breaks it.

And function boundaries are not an obstacle for validity? I guess so (as 
gcc devs expressed such views several times in the past, in various 
contexts) but I'm not sure because DR 236 states otherwise. Initial 
testcase was prepared not to trigger DR 236 and, thus, it's a bit more 
tricky than necessary.

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
 > Fixed on trunk sofar.

While the reduced testcase seems to be fixed, the original testcase 
still fails for me. If a separate function is ok the following testcase 
should be easier to reason about:

extern void *malloc (__SIZE_TYPE__);
extern void abort (void);

__attribute__((noinline,noclone))
void f(int *qi, double *qd)
{
   int i = *qi;
   *qd = 0;
   *qi = i;
}

int main()
{
   int *p = malloc(sizeof(double));

   *p = 1;
   f(p, (double *)p);
   if (*p != 1)
     abort();
}

This bug report was really about optimization of the function f in the 
absence of additional info, e.g. when compiled in a separate TU. 
(noinline+noclone seem to be enough too.) All printfs in the original 
testcase are just to achieve the same outcome without explicit function. 
But maybe I accidentally triggered another gcc bug.

BTW your testcase in comment #5 is interesting because the 
implementation of the function foo seems to affect the optimization of 
the rest of the program, i.e. noinline+noclone provide only one-way 
isolation. Just last week I asked about it elsewhere and here it is. 
Thanks! :-)