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 BBA5A3858C50; Wed, 29 Mar 2023 11:38:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBA5A3858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680089931;
	bh=+21zn1250jVU8xhqMUsodTJv/M9hPayiTEk4UxpZB7A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Mvc8rwwVX1YFnDR03s/m/g4dsyE//Bqto0x3cfhsEh1HWH+qv7odGrJqD9eHs8vad
	 Ly//mpLZIwKHLUJodkiDCTPJj/YEfPjJXQwkLz6zYR30cW5O9mtO3FXo4zO41ukaoD
	 DBNJ9oF2FnKPWhumX+JqX/T2kodjUkzUPQgr7xkg=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C  and
 [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow
 problem
Date: Wed, 29 Mar 2023 11:38:49 +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: 13.0
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc priority
Message-ID: <bug-107561-4-mEPQesQC7p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107561-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107561-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=3D107561

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Priority|P1                          |P3

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we can "mitigate" the diagnostic for g++.dg/pr17488.C with a hack, but f=
or
g++.dg/warn/Warray-bounds-16.C we see

<bb 2> [local count: 1073741824]:
a =3D{v} {CLOBBER};
a.m =3D 0;
_5 =3D operator new [] (0);
a.p =3D _5;
_2 =3D a.m;
if (_2 > 0)
  goto <bb 3>; [89.00%]
else
  goto <bb 5>; [11.00%]

<bb 3> [local count: 955630225]:
_12 =3D (sizetype) _2;
_11 =3D _12 * 4;
__builtin_memset (_5, 0, _11); [tail call]

where we'd have a clear range (_2 > 0) even without the multiplication but
we're only now picking that up.  The bug here is quite the same
missed optimization though, we fail to CSE a.m around the 'operator new [] =
(0)'
call and so obviously dead code remains.

C++ is simply an awful language to work with here.  A static analyzer would
maybe simply look past possibly clobbering calls deriving the code is
likely dead and refrain from diagnosing it.

Note while for g++.dg/warn/Warray-bounds-16.C we are again working inside a
CTOR the issue extends to any code with intermediate allocations via
new or delete expressions.  Yes, we can add some flag like -fnew-is-not-stu=
pid,
but then we couldn't make it the default.  Maybe(?) we can somehow detect
whether we are dealing with overloaded global new/delete with LTO, like
detecting we're resolving it to the copy in libstdc++?  The resolution info
just tells us RESOLVED_DYN though, maybe we can add something like
RESOLVED_STDLIB_DYN and handle a set of known libraries specially?

I'm putting this back to P3, we do have a load more (late) diagnostic
regressions in GCC 13.=