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 EFBB9385021B; Fri, 26 Aug 2022 18:51:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFBB9385021B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1661539863;
	bh=B9JQcCTPgHkTzBITb37EK0JO/Dsu8MniSa3H3fic6hQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=GhC0P2euzj3YcxpXvUTSwLo7ERdsCxKfZVEfrQfravNHa0lYqzGux9aB2oHq+3g0a
	 Li2BNut5j9OQhSmS+JFE1UXBMp/IZB4hFIXTDPmRYQusWIt6q1bGBoVrg0cvqrAzqS
	 TRu0VBCVNgzo2GQgyyJZ6Pa7Gw66PFtOD+fc8L4g=
From: "bergner at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Fri, 26 Aug 2022 18:51:03 +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: bergner 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: <bug-106736-4-mA8r7aVTJK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106736-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106736-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #4)
> Thanks for the comments! One patch guarding these types is attached, it c=
an
> fix the ICE.

That won't work, because that's what we used to do! :-)   In PR96125, the t=
est
case there is compiled with -mcpu=3Dpower8, but uses a pragma/target attrib=
ute to
compile a function with -mcpu=3Dpower10/-mmma.  The problem is that built-i=
n and
target type initialization is only done once, so we can't tell from the
explicit options being used, whether there will be a function later that us=
es a
pragma/target attribute, so we have to assume there will be.

Therefore, we have to always initialize them as we do now, but somehow later
catch any illegal usage.  Ideas on how to do that welcome! :-)=