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 833C23858D37; Tue, 23 May 2023 14:00:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 833C23858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684850404;
	bh=kbYdz683QXvumacoS/4xEojCb7wD+yZxy56ydcBrSt8=;
	h=From:To:Subject:Date:From;
	b=QWc5yC5PmuylDcedibiMZmb4K3qMbTJ1eIZkzhJySK+WV+FrpNy16D+XDeKAtObmn
	 L8VtKwXunMBHOBnFZxqSO5s0pYI5/zrtomoqeSYeDbVacD7HYhyFscOao77gREucIa
	 IK5hA9/lnZHpiLRjHjKL+6KaJ/V1r+CCK3E0Q9Xs=
From: "arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/109945] New: Escape analysis hates copy elision: different
 result with -O1 vs -O2
Date: Tue, 23 May 2023 14:00:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: arthur.j.odwyer at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 keywords bug_severity priority component assigned_to reporter
 target_milestone
Message-ID: <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

            Bug ID: 109945
           Summary: Escape analysis hates copy elision: different result
                    with -O1 vs -O2
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Background:
https://quuxplusone.github.io/blog/2021/03/07/copy-elision-borks-escape-ana=
lysis/
The background paradox here is, "When class Widget is subject to copy elisi=
on,
then any unseen function can return a prvalue Widget whose address has alre=
ady
escaped!" Aaron Puchert and I were discussing this, with examples. (He thin=
ks
the resolution of the paradox is "you *must* treat a lot more things as
escaped"; I think an acceptable resolution would be "you may treat copy-eli=
sion
itself as a magic that invalidates pointers and references even though the
object is still in the same place.")
But then I came up with an example that didn't rely on copy elision at all.=
 We
both agree this code is perfectly well-defined =E2=80=94 yet GCC miscompile=
s it at -O1!

// https://godbolt.org/z/bTnv68nhG
struct Widget {
    Widget();
    int i =3D 1;
    int a[4];
};
Widget *global =3D nullptr;
Widget::Widget() { global =3D this; }
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
}

gcc -O0 and gcc -O2 both correctly return 0 from main.
gcc -O1 wrongly returns 1 from main.

*At least* since C++17, I think the -O1 result is flat-out wrong codegen. We
have `global =3D=3D &w`, and so the call to `g()` can definitely modify `w.=
i`.

(Clang always treats Widgets' addresses as escaped, no matter what Widget l=
ooks
like. MSVC's escape analysis is more complicated and I have not yet been ab=
le
to trick it into wrong codegen.)=