https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
> bergner@ltcden2-lp1:ICE$ gcc -S -m64 -O2 -mcpu=power5 -mabi=no-altivec bug.c
> bug.c:3:1: internal compiler error: in rs6000_option_override_internal, at
> config/rs6000/rs6000.cc:3952
-mabi={no-,}altivec is only for the 32-bit ABIs. All the 64-bit ABIs had
either
only compatible changes to support VMX, or only ever had support for it in the
first place.
> That said, how does your patch handle the following test case?
>
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
> return 0;
> }
It should hard error for it. That combination is not valid. VSX requires VMX.
> ...currently, this compiles with with no error or warning message which
> seems wrong to me.
Yup.
The only reason ever to disable VMX or similar, is if the target (OS) you are
compiling for does (potentially) not support it. The kernel usually. But
there can be userspace problems as well, {set,long}jmp and [gs]etcontext
usually. But if the target does support VMX (or VSX), the compiler should
never disable generating it when it has a -mcpu= in effect that supports it!
Even if the -mabi= does not support V*X, that only effects what is done at
function boundaries!
