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