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 053443858C62; Tue,  5 Sep 2023 18:00:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 053443858C62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1693936841;
	bh=B9SCZtXc0MYqBwhSNg0ylUyKKbKm1Ca2OI7CGSwhk8A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZLSaibul3yBTt5AVGpSnv7btSQRUrLmsK9Sd7cEaWSDt8diYE4fDosp9XIarYJrdo
	 D/cyorwbbUjaWxKR24EXWGOvv7y/WPgg8SWEd4bQ56r4Nnuuv/C8MjWQIxeOZY9O7S
	 SW2S4ha/LWvLOEH96MQKd6lImvQK5yocuJzXxMYU=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value
 parameters are mishandled since GCC 9
Date: Tue, 05 Sep 2023 18:00:40 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: accepts-invalid, rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-111284-4-3Zy5YygJ9W@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111284-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111284-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=3D111284

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
private isn't needed.
struct S {
  S () =3D default;
  constexpr S (const S &) noexcept : s{this} {}
  constexpr S & operator=3D (const S &) noexcept { return *this; }
  constexpr bool foo () const noexcept { return s =3D=3D this; }
  S *s =3D this;
};

constexpr bool
bar (S x) noexcept
{
  return x.foo ();
}

static_assert (bar (S {}), "");
static_assert ([] (S x) { return x.foo (); } (S {}), "");

The most important change in that commit was to make a copy of the inline b=
ody
before it is destructively changed during genericization.  On the other sid=
e,
one of the important changes genericization does is adjust accesses to
DECL_BY_REFERENCE PARM_DECLs/RESULT_DECLs.
During the evaluation of static assert, I see we are first evaluating
bar (&TARGET_EXPR <D.2583, <<< Unknown tree: aggr_init_expr
  4
  __ct_comp=20
  D.2583
  (struct S *) <<< Unknown tree: void_cst >>> >>>>);
which means that expression is adjusted for the passing of invisiref parms,=
 we
are
passing there address of D.2583 variable with S type which is constructed.
But, later on when trying to constexpr evaluate the body of bar, we see
S::foo (&x);
call, so passing address of x to the method, where x is PARM_DECL with S ty=
pe.
DECL_BY_REFERENCE even isn't set (yet) on it.
I guess we need to somewhere during constexpr evaluation take into account =
that
S pointer/reference has been passed to the function (to an invisiref parm) =
and
the function body still uses it directly rather than changing it into a
pointer/reference and dereferencing it.=