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 06C843858D20; Tue, 20 Feb 2024 10:45:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06C843858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1708425944;
	bh=JPD2QgxU0qy1OJQG8vM2NPPrZEfmaAYzsRy3QZNSFvc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=uLJJmd653oyZv3bLZMt2pWIb3xH+D66Esby7azGzBFmMdgSejsSpNHnvmjc/cjnw6
	 lcVhm0o0q+Q7L80eYGr/HkEKRQIxsu+J1q67vIhXfSaVeGGUzMV+3QoDRLhLKZKhR8
	 1p3CgNNrL3FqcylaNDeyoE/6PlB+CqfTrd0zUA8E=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109945] Escape analysis hates copy elision:
 different result with -O1 vs -O2
Date: Tue, 20 Feb 2024 10:45:43 +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: jakub 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-109945-4-dfK23ILG8u@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109945-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109945-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=3D109945

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Changing what types have TREE_ADDRESSABLE flag on it would cause significant
ABI changes, that is not what we can do.
Widget above does not have trivial default constructor, but has trivial copy
constructor and trivial destructor, it certainly can be copied.
Consider adjusted testcase:
struct Widget {
    Widget();
    long i =3D 1;
    long j =3D 2;
};
Widget *global =3D nullptr;
Widget::Widget() { global =3D this; }
[[gnu::noipa]] Widget make() { return Widget(); }
void g() { global->i =3D 42; }
int main() {
  Widget w =3D make();
  int i =3D w.i;
  g();
  return (i =3D=3D w.i);
    // Does this need to be reloaded and
    // compared? or is it obviously true?=20=20
}
On x86_64, this Widget is returned in registers, so the assumptions the
testcase has
look wrong to me, dereferencing global when the return went out of scope lo=
oks
UB to me.
On i686, this Widget is returned in memory.  Is the testcase valid there or=
 UB
as well?

Jason, thoughts on this?

If the above testcase is for some reason valid conditionally (on some targe=
ts,
not on others, depending on calling conventions), I think we could check
TREE_ADDRESSABLE on the called function RESULT_DECL if it has some extra fl=
ag
set by the FE that there was guaranteed copy ellision (and assume worst cas=
e if
we don't see the called function (we then don't know if it has been compile=
d by
C or C++ etc.) or it has noipa attribute).=