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).