[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

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

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

--- Comment #27 from Erhard F. <erhard_f at mailbox dot org> ---
(In reply to Peter Bergner from comment #25)
> I think this is the solution we want, meaning if the target we're building
> supports VSX, then we'll build the IEEE128 bits, otherwise, we won't build
> them.  I think that is the only sane answer.
> 
> I also believe that if the user specifies a -mcpu= option (either implicitly
> or explicitly) that doesn't support VSX (eg, power4, or 7450, etc.) and they
> also explicitly use -mvsx, then we should emit an error message saying the
> -mcpu= option doesn't support using -mvsx at the same time.  Ditto for
> -maltivec, -mmma, etc.  We should not be silently enabling instruction
> support over and above their -mcpu= selection just because its needed for
> VSX/Altivec/MMA/etc. support.  Currently we don't emit an error and instead
> silently enable generating instructions not supported by their -mcpu= option.
As user I would favor this approach.

Because that way I get an error message I actually understand at the early
stages of building a package. Not silently broken code and illegal
opcode/unrecognized opcode messages later on which make me wonder where they
come from when I specified -mcpu=7450 or -mcpu=970.

Unrelated to libgcc but similar issues would be bug #97367 or my Gentoo
Downstream bug report about nettle-3.9.1 (https://bugs.gentoo.org/920234).