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 7E7FE385780D; Mon, 25 Jul 2022 09:59:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E7FE385780D
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are
 working)
Date: Mon, 25 Jul 2022 09:59:34 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 10.4.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rearnsha at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106187-4-rY5pjBALlv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106187-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106187-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2022 09:59:34 -0000

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

--- 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 loca=
tion
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 =3D m;   // m dead
 n =3D y;   // n born
 ...
}

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