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 D75DE3858C83; Tue, 26 Apr 2022 15:54:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D75DE3858C83
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/100252] [9/10/11/12 Regression] Internal compiler error
 during template instantiation
Date: Tue, 26 Apr 2022 15:54:32 +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: 10.3.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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: 9.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-100252-4-w99zZcwLO1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-100252-4@http.gcc.gnu.org/bugzilla/>
References: <bug-100252-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2022 15:54:32 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100252

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
When we are cp_parser_late_parsing_nsdmi for "int y =3D A{x}.y;" we perform
finish_compound_literal on type=3DA, compound_literal=3D{((struct B *) this=
)->x}.=20
When digesting this initializer, we call get_nsdmi which creates a
PLACEHOLDER_EXPR for A -- we don't have any object to refer to yet.  After
digesting, we have

  {.x=3D((struct B *) this)->x, .y=3D(&<PLACEHOLDER_EXPR struct A>)->x}

and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole c=
tor
CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and returns

  TARGET_EXPR <D.2384, {.x=3D((struct B *) this)->x, .y=3D(&<PLACEHOLDER_EX=
PR
struct A>)->x}>

(*)

Then we get to

  B b =3D {};

and call store_init_value, which digest the {}, which produces

  {.x=3DNON_LVALUE_EXPR <0>, .y=3D(TARGET_EXPR <D.2395, {.x=3D(&<PLACEHOLDE=
R_EXPR
struct B>)->x, .y=3D(&<PLACEHOLDER_EXPR struct A>)->x}>).y}

The call to replace_placeholders in store_init_value will not do anything:
we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only a
sub-expression, so replace_placeholders does nothing, so the <PLACEHOLDER_E=
XPR
struct B> stays even though now it was the perfect time to replace it becau=
se
we have an object for it: 'b'.

Later, in cp_gimplify_init_expr the *expr_p is

  D.2395 =3D {.x=3D(&<PLACEHOLDER_EXPR struct B>)->x, .y=3D(&<PLACEHOLDER_E=
XPR struct
A>)->x}

where D.2395 is of type A, but we crash because we hit <PLACEHOLDER_EXPR st=
ruct
B>, which has a different type.


Now here's an idea how we could fix this: at the (*) point in
finish_compound_literal we could replace <PLACEHOLDER_EXPR struct A> with
D.2384 because now we have an object!  Then clear
CONSTRUCTOR_PLACEHOLDER_BOUNDARY, because we no longer have a PLACEHOLDER_E=
XPR
in the {}.  Then store_init_value will be able to replace <PLACEHOLDER_EXPR
struct B> with 'b', and we should be good to go.=