From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4D2253858D28; Tue, 20 Feb 2024 12:07:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D2253858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708430835; bh=nl8Mq4mGg+2+lJLFqc/cqyJfXULDFxmU763luzmj7XU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=avxWCyGKHMpzfccako6v7NW8rf4dryACPnPQlWqRpLBdkWzPocslQTyKkJWGZwPJU ppaR4Tx7uyryB41T4qttMT2m+ynbfBNdrO6oc8LUyT1FowNQJVmtNGkC3Xf2WxkLc+ frPoNuzq5KWjh2k2yREkFIf7d3/LdxebKKxkEg0E= From: "redi at gcc dot 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 12:07:14 +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: redi 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109945 --- Comment #25 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #9) > struct Widget { > int i; > int a[4]; > }; > Widget *global =3D 0; > Widget make2() { Widget w; w.i =3D 1; global =3D &w; return w; } > void g() { global->i =3D 42; } > int main() { > Widget w =3D make2(); > 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 > } > ``` >=20 > But does w go out of the scope at the end of make2? Yes. This example has undefined behaviour in all versions of C++. w is a local variable, its lifetime is the function body of make2, and glob= al becomes an invalid pointer after make2 returns, so dereferencing global in = g() is UB. > Similar question to make > in the original testcase, does the temp go out of scope? Before C++17 yes, it was undefined for exactly the same reasons. That changed in C++17 and now a temporary is not "materialized" until as la= te as possible. In many cases there would be no temporary, the prvalue returne= d by make() would initialize w in main without any intermediate temporary. However, [class.temporary] p3 explicitly allows the compiler to create a temporary object when returning a class with a trivial copy constructor and trivial (or deleted) destructor. This is permitted precisely to allow what = the x86_64 ABI requires: the return value is passed in registers. Completely eliding the creation and copy of a temporary would have required an ABI bre= ak. So the example in comment 0 is also an incorrect program, even in C++17. It= 's unspecified whether the prvalue created in make() is only materialized when constructing w (so there is never any temporary Widget) or whether the prva= lue is materialized to a temporary which then gets copied to w using the trivial copy constructor. Since it's unspecified, the program cannot rely on any particular behaviour. The 'global' pointer might point to w, or it might point to a temporary whi= ch has gone out of scope, and in the latter case, dereferencing it in g() is U= B. So inconsistent behaviour with different optimization settings and/or noipa attributes seems fine. Either global =3D=3D &w or the program has UB. I think this is INVALID.=