https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > (In reply to Peter Bergner from comment #2) > > (In reply to Jeevitha from comment #1) > > > This test case requires a Power7 or above due to the ieeelongdouble ABI. > > > The test case includes "ppc_float128_sw", but this is not helpful. We can > > > use the target check "ppc_ieee128_ok" to verify IEEE support. > > > > It's "unhelpful" since the ppc_float128_sw test adds -mvsx to the test case > > fragment and we currently have a bug in the rs6000 backend where -mvsx > > incorrectly silently enables Power7 code generation, rather than flagging an > > error on -mcpu=XXX compiles where XXX is older than Power7, making us > > That is IMHO not a bug, but expected behavior, that is how gcc behaves on > tons of other architectures. The ISA flags are additive to the -march or > -mcpu choice, if you ask for -mcpu=power4 -mvsx, you simply need to run the > code on Power4 CPU or newer which is backwards compatible with that, and > need to have the VSX ISA as well (so effectively Power7 then). > Users shouldn't be forced to use just -mcpu=, they can choose some CPU, or > just go with whatever default there is, but then they can add or take away > from that some ISAs. Users can not randomly add support for newer insns. If you choose to support some newer system, GCC can use *all* new insns of that system. We used fine- grained control like you propose for a long time (and for a long time we have been trying to get rid of it). But that way lies madness: supporting all kinds of random configurations means in all fallback paths you need to as well, and there is no way you will test that properly, etc. But the bugs Peter talks about are different. First, the -mvsx option used to enable *all* ISA 2.06 support, all p7 support. Not good. And secondly, the ppc_float128_sw selector always adds -mvsx in its test, while it should be testing if it already was enabled!
