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 rguent...@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.
