From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CC3D03858D28; Tue, 27 Jun 2023 10:03:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC3D03858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1687860194;
	bh=RAgt24EfsAQpHF8NDGvqi89Mcha9awnwEAMvV6sY3jA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=KTMJdoHnVr1pTXsnYryWP4FKHZSUyLxqvD9D7+pneaEBBOFFI3UopfVks3qurkZfl
	 YE36ExgNWARCtrxyhry6AvOC/bnDqwkIfEJuraoicCdr207zcFIHje6/LSfMnWShk1
	 al6bE2+to7Ih2Jd33Wy316kskc0/AATYaXT8Ew2A=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is
 miscompiled by RTL scheduling after reload
Date: Tue, 27 Jun 2023 10:03:11 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110237-4-1pGRnDNlRw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110237-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110237-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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=3D110237
>=20
> --- 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.
> >=20
> > int a;
> > int b;
> >=20
> > int main()
> > {
> >   a =3D 1;
> >   b =3D 2;
> >   if (&a + 1 =3D=3D &b) // equality compare of unrelated pointers OK
> >     {
> >       long x =3D *(long *)&a; // access outside of 'a' not OK
> >       if (x !=3D 0x0000000100000002)
> >         abort ();
> >     }
> > }
> >=20
> > 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.
>=20
> 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 se=
em to
> have a problem here and might need to be able to annotate types or indivi=
dual
> 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.=