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 BE2ED385773F; Thu, 11 May 2023 09:39:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE2ED385773F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683797989;
	bh=40YOIVoj1Iw8qItPoIzNTtHzZpVGxwRqO1XmlJUXHUc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=oT1O+wXO2Dvimd7b/jYPjV4+cJpwFOv+pkG8V4rOZHnXCEoTSdpZU91hIo1t+1VgZ
	 Aa9FTZUiajvi4RSYr6wX/qc4OklcQhw9XCpKCyVyk3wYY7MyVL0XD2AbKB/GbjQwiB
	 8HW8JfVCIL++2hLfHCVL9T1WCUFfB1BhXWXUHf1s=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109791] -Wstringop-overflow warning with -O3
 and _GLIBCXX_USE_CXX11_ABI=0
Date: Thu, 11 May 2023 09:39:47 +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: 12.1.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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-109791-4-5RXW1UYhSs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109791-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109791-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=3D109791

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
DOMs scoped tables do not help.  The crux is really the PHI:

 __i_14 =3D PHI <&MEM <char[3]> [(void *)&str + 1B](10), &MEM <char[3]>
> [(void *)&str + 2B](9)>

there's no single value that exposes &str + offset.

For

  _4 =3D (unsigned long) &MEM <char[3]> [(void *)&str + 2B];

we might want to go and express it as

  _4' =3D (unsigned long) &str;
  _4  =3D _4' + 2;

but the issue with the PHI node remains unless we sink the &str part
(but there's many uses of __i_14).  I guess it's still the "easiest"
way to get rangers help.  Aka make

 # __i_14' =3D PHI <1(10), 2(9)>
 __i_14 =3D &str + __i_14'; // would be a POINTER_PLUS_EXPR

it's probably still not a complete fix but maybe a good start.  Of course
it increases the number of stmts - &MEM[&str + 1B] was an 'invariant'
(of course the PHI result isn't).  There's not a good place for this
transform - we never "fold" PHIs (and this would be an un-folding).=