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 323543858C39; Fri, 12 Apr 2024 10:51:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 323543858C39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712919106;
	bh=YiFcKaJ5dmC3L1ArF1khIzZPS2M7UgtEMYzEz/5biAE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jsHhgZHlpA69YQn412AKQpb7fwl/jVIFv80XUE/g50scCFKsIhm48VgJsu2zY0qdJ
	 6+BCTNzw440snCn/dctXQF8MZqg7bvjQauG/gu8PMF5NQj+GefRdTj/eWKtygO/NzU
	 Wqbg6dvOcI5WR8LQV6/GtVlSgNX58JtHmje3cG8w=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111231] [12/13/14 regression] armhf: Miscompilation with
 -O2/-fno-exceptions level (-fno-tree-vectorize is working)
Date: Fri, 12 Apr 2024 10:51:45 +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: 13.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111231-4-G2JNg7JVR9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111231-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111231-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=3D111231

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #27)
> (In reply to Richard Earnshaw from comment #26)
> > (In reply to Richard Biener from comment #25)
> > > I think it's more interesting why
> > >=20
> > > * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)=
] =3D
> > > {r0:SI..r3:SI}
> > >=20
> > > isn't considered as dependence?  Why does the earlier insn even come =
into
> > > play?  What's the breaking transform?  I guess insn 119 and 120 are
> > > exchanged?
> >=20
> > Because 119 was deleted by postreload.  Doh! I should have spotted that.
>=20
> But that ought to be ok, insn 115 is a store in alias set 0, so is picked=
 up
> by later alias analysis.  It's just that the compiler then digs deeper and
> decides that that isn't an addressable object (at the gimple level) so th=
ere
> can't really be a dependency.

>   112: r214:SI=3Dr109:SI-0x60
>   115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0=
 S4
> A64)] =3D {r0:SI..r3:SI}
> ; _179 =3D D.33805
>   117: r217:SI=3Dr109:SI-0x60
>   118: {r0:SI..r3:SI} =3D [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=3Dr109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =3D
> {r0:SI..r3:SI}
> ; r218 =3D _179
> * 120: r218:V8HI=3D[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]

but 115 doesn't store at the same address as 119?  Yes, it has the same
value.

So it doesn't seem to be stack-slot sharing.  When we'd share D.33805
with *_179 then we'd have made D.33805 TREE_ADDRESSABLE and adjusted
points-to sets accordingly in update_alias_info_with_stack_vars.=