From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9084B385E449; Wed, 30 Mar 2022 13:51:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9084B385E449 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/104583] [10/11/12 regression] ICE dolphin-emu at cp/cp-gimplify.cc:746 Date: Wed, 30 Mar 2022 13:51:34 +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: 12.0 X-Bugzilla-Keywords: ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.4 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2022 13:51:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104583 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb commit r12-7919-gf8c1f29a0b47b4b4a3c1506678f7ca2ce4b7ffbb Author: Marek Polacek Date: Fri Mar 25 17:46:07 2022 -0400 c++: ICE with aggregate assignment and DMI [PR104583] The attached 93280 test no longer ICEs but looks like it was never adde= d to the testsuite. The 104583 test, modified so that it closely resembles 9328= 0, still ICEs. The problem is that in 104583 we have a value-init from {} (the line A a{};), so this code in convert_like_internal 7960 /* If we're initializing from {}, it's value-initializati= on.=20 */ 7961 if (BRACE_ENCLOSED_INITIALIZER_P (expr) 7962 && CONSTRUCTOR_NELTS (expr) =3D=3D 0 7963 && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype) 7964 && !processing_template_decl) 7965 { 7966 bool direct =3D CONSTRUCTOR_IS_DIRECT_INIT (expr); ... 7974 TARGET_EXPR_DIRECT_INIT_P (expr) =3D direct; sets TARGET_EXPR_DIRECT_INIT_P. This does not happen in 93280 where we initialize from {0}. In 104583, when gimplifying, the d =3D {}; line, we have d =3D {.a=3DTARGET_EXPR >> >>>>} where the TARGET_EXPR is the one with TARGET_EXPR_DIRECT_INIT_P set. In gimplify_init_ctor_preeval we do 4724 FOR_EACH_VEC_SAFE_ELT (v, ix, ce) 4725 gimplify_init_ctor_preeval (&ce->value, pre_p, post_p, da= ta); so we gimplify the TARGET_EXPR, crashing at 744 case TARGET_EXPR: 745 /* A TARGET_EXPR that expresses direct-initialization should have been 746 elided by cp_gimplify_init_expr. */ 747 gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p)); but there is no INIT_EXPR so cp_gimplify_init_expr was never called! Now, the fix for c++/93280 says "let's only set TARGET_EXPR_DIRECT_INIT_P when we're using the DMI= in a constructor." and the comment talks about the full initialization. Is is accurate to say that our TARGET_EXPR does not represent the full initialization, because it only initializes the 'a' subobject? If so, then maybe get_nsdmi should clear TARGET_EXPR_DIRECT_INIT_P when in_ctor is false. I've compared the 93280.s and 104583.s files, they differ only in one movl $0, so there are no extra calls and similar. PR c++/93280 PR c++/104583 gcc/cp/ChangeLog: * init.cc (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P to in_ctor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-list7.C: New test. * g++.dg/cpp0x/nsdmi-list8.C: New test.=