[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #7)
> -m64 requires 64-bit instructions.  We will ICE if we try to generate code
> for -m64 without support for 64-bit insns enabled in the compiler.  For
> example, the stdu insn is required to implement the ABI sanely.
> 

The current behavior for one explicit command line option -m64 doesn't violate
the comment, the explicitly given -m64 will enable powerpc64 all the time, it
makes -m64 compilation always have 64-bit insns enabled. It's the same for both
cases before and after r13-4894.

> If the user said they want a -mcpu= for a CPU that has no 64-bit insns,
> but also wants to use -m64, we should just say sorry, that won't fly.

I agree that this is a sensible thing to look into and make. But to change the
behavior like this fully (on Linux, aix and darwin, 64 bit env w/ or w/o
explicit -m64) is a big adjustment comparing with the previous behaviors.

Since for the case that "the explicit option -m64 + cpu without 64-bit insn +
Linux/aix/darwin" it doesn't emit errors before, for the cases that "no
explicit option -m64 + cpu without 64-bit insn + aix/darwin" it only emits
warnings before. Only for the case "no explicit option -m64 + cpu without
64-bit insn + Linux", it emits error before r13-4894. After the culprit commit
it changes to not emit errors, this part is a regression, the proposed patch
can fix it.
But for the others in which cases we don't emit error before (for both cases
before and after r13-4894), to make them to emit errors is new behavior, it
could cost non-trivial efforts (at least on testing and some fixing on possible
fallouts).