From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4737D3858C41; Mon, 11 Sep 2023 11:32:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4737D3858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694431950; bh=5DP30arUIvVp6V/T+7kyLTHr+EiaeyuE7uxZmvRyq7Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Hz4jXsN3npoeHDhA8c4YMbXNOLh1s7aixIZQyVWVMuLS9WVwNWf+Sr9gujzfXUPQu Ty1WQq5iUB7KVRMRdp4rtlhlEX97RWMt+A1I/Yc2HBOrPnupqoQJJr0Ydc3UOAJJns c7NyQC5LY7IUYnVXbXG9KcLWFDLhFLOJ4zrsa5DA= From: "jakub at gcc dot 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: Mon, 11 Sep 2023 11:32:29 +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: 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=3D111284 --- Comment #6 from Jakub Jelinek --- Actually, the binding of parms seems to work fine. But am out of ideas where this should be fixed. When evaluating the comparison, we have lhs (const struct S *) (struct S *) ((const struct S *) this)->s and rhs (const struct S *) this and we constant evaluate both. In both cases we find this (foo's artificial argument in #c2) is &x where x is bar's PARM_DECL. But in the lhs case, ->= is applied to it, so x is evaluated as prvalue as {.s=3D&D.2836} where D.2836 is the local te= mp built for AGGR_INIT_EXPR - but nothing during the constexpr evaluation actu= ally knows that &D.2836 is actually the address of the x argument. So, lhs folds into &D.2836 with some cast. While then constexpr evaluating rhs sees just accessing this which is &x an= d in that case x is used as an lvalue, so the folds into &x. And those two are = not equal. So, I think we need to treat somewhere the arguments (and return values?) w= ith TREE_ADDRESSABLE types during constexpr evaluations actually as references rather than what they are in the source (so what we do after genericization= ).=