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

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

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

--- Comment #25 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Michael Meissner from comment #23)
> 3) Only build the IEEE 128-bit libgcc bits if the user configured the
> compiler with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9,
> --with-cpu=power10 (and in the future --with-cpu=power11 or
> --with-cpu=future).  This could be code that if __VSX__ is not defined, the
> libgcc support functions won't get built.  We would then remove the -mvsx
> option from the library support functions.

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.