------- Comment #6 from vsxo at hotmail dot com 2005-11-17 21:26 ------- Sure, sure. But -mcpu=970 -mno-altivec makes sense: it just causes the SIMD unit to be unused. -mcpu=G3 -maltivec does not make sense. I don't agree that it should be possible to override the explicitly selected architecture, WITHOUT WARNING or error. Imagine a compiler configured for a cross-compiling environment, as Apple's fat binaries. What do you do with -mcpu=pentium-m -mpowerpc-gpopt ? Output code for the G5 knowing full well the user just asked for pentium-m code? Ignore the incompatible specifier? The most sensical thing to do in this case is to give an error and abort.
In reaction to the references: I don't see the bug. That is, I don't see how the earlier behaviour is incompatible with the documentation you refer to (which is given in the manpage too). To me it makes more sense to ignore an unsupported option than to 'upgrade' the selected target cpu and generate code that crashes. -mpowerpc64 is a bit different in this in that the manpage clearly mentions that is belongs to ppc64: a G4 clearly doesn't. There, I can't criticise (though a warning would still be preferrable). And I see this: "Specifying the -mcpu=cpu_type overrides the specification of these options. " This suggests rather explicitly that -mpowerpc-gpopt -mcpu=G4 should undo the selection of the GPOPT instruction set. The documentation is vague in that the G4 nor the G5 are mentioned among the Motorola and IBM processors listed in the description of these arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
