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.
