From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E0AEA3858D28; Wed, 7 Sep 2022 06:51:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E0AEA3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662533502; bh=jF5NXmXzaxM49jqC/GCV6d2tRTK3tO80XUNHts7s1Jw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wV0BgJVdGzWu1gnoQ/z9wUzc4MSm0xreTrkZYAsVyxYcR8qFS7xNl15vV4q9VV7aV cQdyvJAMdx0yhwvxmN+GiWfo5ePRgeLgIKRbq7LQVjTB0X4/51mYIZA9Sxk+//rIld z/qSpfxpOfQeORnKe9At0ThOYikF6PnQnr6JEaac= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333 Date: Wed, 07 Sep 2022 06:51:41 +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-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.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=3D106736 --- Comment #12 from Kewen Lin --- (In reply to Segher Boessenkool from comment #11) > (In reply to Peter Bergner from comment #10) > > (In reply to Segher Boessenkool from comment #9) > > > When MMA is not enabled, > > ... > > > the __vector_{quad,pair} types should not exist,=20 > >=20 > > Unfortunately, target type initialization only occurs once at the very > > beginning >=20 > That is what indirection is for (or copying more likely, in this case). >=20 > > and if we don't initialize them because of the command line > > options in affect at the time, then we get problems like PR96125, so we= have > > to initialize these types always, just like we do for built-in function= s. >=20 > I don't understand? Since we need to support some target pragma/attribute usage, we have to initialize those built-in functions globally, otherwise for example assuming command line option specifying cpu type power8, we don't initialize mma bif, meanwhile there is one function with mma target attribute using mma bif, it will raise error for no such bif. Although we always initialize those bifs = , we will still check their validity when expanding. But your question makes me consider that if we can apply the similar idea f= or built-in type. Now we emit error msg when expanding bif by checking its supported (ENB...), if we can find somewhere in expander for checking built= -in type, we can add one hook there. I'll have a further look on this.=