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 848FA3858423; Tue, 10 Oct 2023 10:37:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 848FA3858423
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1696934255;
	bh=Nyp5SNraeVffj/6Yy8Zp8zeAgt+Qav42bHAJryr562Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=kk1OGCwmh4yAA+bgQo6Uf6fAEfml9SNtmlwj5EsmKuvUeQjiQLwMRrzw1za7cMX6X
	 jYlv4n4ZP71Qnucj+d+8hOFwBT9xyjjslADayXPvNibLHdlumD+4Ht96mrM7ml0/u7
	 jVZcKxleo+62P+Gxruq1tLf2ujHyXH0BXuqzN39M=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3
 on x86_64-linux-gnu since r13-455-g1fe04c497d
Date: Tue, 10 Oct 2023 10:37:34 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.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: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111519-4-x9csp7UTDQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111519-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111519-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=3D111519

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> Created attachment 56089 [details]
> patch
>=20
> This patch (against the 13 branch) fixes the bug but it might be a bit
> conservative since some entries (the _addr one for example) may not have
> a live virtual use.  Maybe getting the relevant one from up the call chain
> is better.
>=20
> I'm going to throw this at testing but expect some testsuite fallout beca=
use
> of this conservativeness.

It causes

FAIL: gcc.dg/Wstringop-overflow-69.c  (test for warnings, line 60)
FAIL: gcc.dg/Wstringop-overflow-69.c  (test for warnings, line 62)

the testcase has

  *(VC4*)a2 =3D c4;       // { dg-warning "writing 4 bytes into a region of=
 size
2" }
  *(VC4*)a3 =3D c4;       // { dg-warning "writing 4 bytes into a region of=
 size
3" }
  *(VC8*)a4 =3D c8;       // { dg-warning "writing 8 bytes into a region of=
 size
4" }
  *(VC8*)a7 =3D c8;       // { dg-warning "writing 8 bytes into a region of=
 size
7" }

and the later of the two assignments from c4 and c8 fail to be diagnosed
as their load is CSEd to a definition before the earlier of the two
assignments.  Which means the fix is working, not sure if we want to beef
it up with an alias walk, that definitely would require careful looking
as to what random trees we feed into this kitchen-sink routine.

I'm inclined to XFAIL the sub-test, at least on branches, and only maybe
fix it on trunk (well, not myself actually).=