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 83CE63858CDA; Tue, 10 Jan 2023 01:45:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83CE63858CDA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1673315133;
	bh=N7VPkhf8B0EcaZwGsJwl/PC44og6OIIawxX6LFnCuXg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=o5FIn7cSQXIRq9py9OawwITSfCGc/dCraZeGT/q97ajaK8TwZe89IWZQNqHKv7wIZ
	 9E2/qBNd3ztt0FuYCkTo7525X7fFWGB5QKVJ0omGH9fPkaBEVykhe9GjF2V5XJW1en
	 fPDuyKi1rufHGLylZTKDeXETaCKNeoN4FcK7qFxc=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108240] [13 Regression] ICE in emit_library_call_value_1
 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
Date: Tue, 10 Jan 2023 01:45:30 +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: linkw at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
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-108240-4-r2gBZYzdiC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108240-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108240-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=3D108240

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Kewen Lin from comment #3)
> > With the culprit commit r13-4894, we always implicitly enable powerpc64=
 for
> > both explicit and implicit 64 bit, it's the same as before for the expl=
icit
> > 64 bit case, but for the implicit 64 bit case, there is no chance for t=
he
> > used cpu to unset powerpc64 (like this case). To keep it consistent wit=
h the
> > previous, the fix can be to only enable powerpc64 implicitly for explic=
it 64
> > bit, while let it be for implicit 64 bit.
>=20
> No?  If the user says to use a CPU without 64-bit instructions, while the
> user also says we require 64-bit insns (via -m64), we should just error.

But both the previous behavior (before r13-4894) and the current behavior
(starting from r13-4894) honour the given explicit -m64, it would always en=
able
-mpowerpc64 at the same time without any errors/warnings.

> Not hide the problem (and cause many more problems!)
>=20

The behavior change is for the case without any explicit -m64 but the
TARGET_DEFAULT has 64 bit set (implicit -m64).  And yes, different from the
previous behavior, the current behavior hides the error/warning and force t=
he
-mpower64, so I posted one patch at:

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609492.html

It would allow that powerpc64 gets unset if the user says to use a CPU with=
out
64-bit instructions and with implicit 64 bit.=