[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Jun 2023, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
> 
> --- Comment #21 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #19)
> > But the size argument doesn't have anything to do with TBAA (and
> > may_alias is about TBAA).  I don't think we have any way to circumvent
> > C object access rules.  That is, for example, with -fno-strict-aliasing
> > the following isn't going to work.
> > 
> > int a;
> > int b;
> > 
> > int main()
> > {
> >   a = 1;
> >   b = 2;
> >   if (&a + 1 == &b) // equality compare of unrelated pointers OK
> >     {
> >       long x = *(long *)&a; // access outside of 'a' not OK
> >       if (x != 0x0000000100000002)
> >         abort ();
> >     }
> > }
> > 
> > there's no command-line flag or attribute to form a pointer
> > to an object composing 'a' and 'b' besides changing how the
> > storage is declared.
> 
> But store-merging and SLP can introduce a wide long-sized access where on
> source level you had two adjacent loads or even memcpy's, so we really seem to
> have a problem here and might need to be able to annotate types or individual
> accesses as "may-alias-with-oob-ok" in the IR: PR 110431.

But above 'a' and 'b' are not adjacent, they are only verified to be
at runtime.  The only thing we do IIRC is use wider loads to access
properly aligned storage as we know the load wouldn't trap.  That
can lead us to the case you pointed out originally - we load stuff
we will ignore but might cause alias disambiguation to disambiguate
against a store of the original non-widened size.