[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

["rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #37 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #36)

> Note that the only thing we have to do is fix points-to info, the TBAA
> info should be correct and OK even when objects share location, so there's
> nothing we can do at RTL expansion time.

I haven't really studied the way the TBAA code works before, so I may have
missed something, but we clearly end up creating two MEMs for the same location
with non-conflicting alias sets.  So perhaps the problem is when we assign the
alias set when we create the MEM (it's taken from the original type, without
regard to the stack slot assignment).

What would be in the TBAA code to prevent

struct A
{
  int a[4];
};

struct B
{
  float b[4];
};

struct A x;
struct B y;

f ()
{
 struct A m;
 struct B n;
  ...
 x = m;   // m dead
 n = y;   // n born
 ...
}

from moving these two assignments past each other at the RTL level if they
shared the same stack slot?