From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B84283858421; Wed, 29 Mar 2023 10:51:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B84283858421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680087085; bh=l4skGoqZC4aca2PNWv8mgtItQZ53jNrdmbdnMvZsP+I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ljkXl3EmLbipd5UlUY28ITC5YGOp8e8dGSjkRh3UMPJJuTA9NeUeKjNh9TqdULhAT sBeU9Mw5wDalvuyX5DgZ1/Nz8xVFvvqPA62hz2S7aSs4Y5vodMUGPUiVPXCp2E5wwz LiXDRzA6yKyAkxvtrrS9rGzc/6c/JP4cL57p4Lx8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o Date: Wed, 29 Mar 2023 10:51:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: d X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ibuclaw at gdcproject dot org X-Bugzilla-Target-Milestone: 13.0 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=3D109231 --- Comment #23 from Jakub Jelinek --- Ugh, that sounds like an uninitialized use of something somewhere, unfortunately if it is really my commit, I don't understand how it could ca= use it. All it changes is that when tree_versioning is called, the push_struct_func= tion -> allocate_struct_function will not do the if (!abstract_p) { /* Now that we have activated any function-specific attributes that might affect layout, particularly vector modes, relayout each of the parameters and the result. */ relayout_decl (result); for (tree parm =3D DECL_ARGUMENTS (fndecl); parm; parm =3D DECL_CHAIN (parm)) relayout_decl (parm); } and if (!abstract_p && aggregate_value_p (result, fndecl)) { #ifdef PCC_STATIC_STRUCT_RETURN cfun->returns_pcc_struct =3D 1; #endif cfun->returns_struct =3D 1; } parts it did before when abstract_p was false in this case. As I wrote, initialize_cfun has cfun->returns_struct =3D src_cfun->returns_struct; cfun->returns_pcc_struct =3D src_cfun->returns_pcc_struct; a few lines later, so whatever it sets cfun->returns* to should be overritt= en quickly. It is true allocate_stack_function calls before that allocate_stack_usage_i= nfo and stdarg_p but neither of those two should care about those flag or whatever relayout_decl does. Perhaps try to undo my patch in a different way, like --- gcc/tree-inline.cc 2023-03-17 18:59:50.226199917 +0100 +++ gcc/tree-inline.cc 2023-03-29 12:47:21.546947442 +0200 @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c gimple_register_cfg_hooks (); /* Get clean struct function. */ - push_struct_function (new_fndecl, true); + push_struct_function (new_fndecl, false); targetm.target_option.relayout_function (new_fndecl); /* We will rebuild these, so just sanity check that they are empty. */ or --- gcc/tree-inline.cc 2023-03-17 18:59:50.226199917 +0100 +++ gcc/tree-inline.cc 2023-03-29 12:49:16.580255668 +0200 @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c /* Get clean struct function. */ push_struct_function (new_fndecl, true); + relayout_decl (DECL_RESULT (new_fndecl)); + for (tree parm =3D DECL_ARGUMENTS (new_fndecl); parm; parm =3D DECL_CHAIN (parm)) + relayout_decl (parm); targetm.target_option.relayout_function (new_fndecl); + aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) =3D=3D NULL); and see if that changes anything? Of course both of those patches break the PR105554 again. Or if the latter helps, try to comment out the different parts of it too. Seems there was some valgrind for SPARC Solaris out of tree, but can't find= it anymore...=