From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CBC043858410; Fri, 17 Mar 2023 08:59:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CBC043858410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679043556; bh=i0EnbneRef/A78KAgdZVdIGUyoPNNg5fAmtBaRLBkXI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oNpoNQQmW/rYfgOCCaUcZ3PYTnoSAXqBasg69p80yp5NoCeD1U8/m8RSQ2P10tQXM tIZ/orw7GKvUA4NKt/O/HmBTG03eBxciDw0WoszUmw1qOF7z0noP4EcxNVkIG2lCUy h53fGCrzY1yc9Luo0KTi/YLOcNfi2nvKK55Vs1+4= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7 Date: Fri, 17 Mar 2023 08:59:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: 10.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=3D105554 --- Comment #16 from Richard Biener --- (In reply to Jakub Jelinek from comment #14) > So, I have tried > --- gcc/cgraphclones.cc.jj 2023-02-24 11:05:19.704595633 +0100 > +++ gcc/cgraphclones.cc 2023-03-16 19:12:30.452503051 +0100 > @@ -1094,6 +1094,15 @@ cgraph_node::create_version_clone_with_b > || in_lto_p) > new_version_node->unique_name =3D true; >=20=20 > + if (target_attributes) > + { > + push_cfun (DECL_STRUCT_FUNCTION (new_decl)); > + for (tree arg =3D DECL_ARGUMENTS (new_decl); arg; arg =3D DECL_CHA= IN > (arg)) > + if (VECTOR_TYPE_P (TREE_TYPE (arg))) > + SET_DECL_MODE (arg, TYPE_MODE (TREE_TYPE (arg))); > + pop_cfun (); > + } > + > /* Update the call_expr on the edges to call the new version node. */ > update_call_expr (new_version_node); >=20=20 > but that really didn't help, the problem seems to be actually different. >=20 > From what I can see, tree_function_versioning does: > 6240 DECL_RESULT (new_decl) =3D DECL_RESULT (old_decl); > 6241 DECL_ARGUMENTS (new_decl) =3D DECL_ARGUMENTS (old_decl); > 6242 initialize_cfun (new_decl, old_decl, > 6243 new_entry ? new_entry->count : old_entry_block->count); > and initialize_cfun will call allocate_function, which does: > 4845 /* Now that we have activated any function-specific attributes > 4846 that might affect layout, particularly vector modes, relayout > 4847 each of the parameters and the result. */ > 4848 relayout_decl (result); > 4849 for (tree parm =3D DECL_ARGUMENTS (fndecl); parm; > 4850 parm =3D DECL_CHAIN (parm)) > 4851 relayout_decl (parm); > So, we temporarily set DECL_ARGUMENTS and DECL_RESULT of new_decl to > arguments/result of old_decl and allocate_function called relayout_decl on > those, later on we create new arguments (which supposedly have correct > DECL_MODE). But we've changed the old DECL_RESULT/DECL_ARGUMENTS. Ick - that's one of the worst place to do this ... what happens if we postpone setting DECL_RESULT/DECL_ARGUMENTS to after initialize_cfun (and remove the setting of them there)? I suppose on its own this doesn't fix the original issue but possibly clobbering the original function arg decls layouts looks wrong ...=