https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |meissner at gcc dot gnu.org
--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #3)
> Something like that.
>
> But why would we want to disable generation of VSX or VMX insns at all?
> This is similar to disabling generation of popcntd insns if you do not like
> those!
>
> Having generation of V*X insns enabled is completely independent of whether
> something special is done for them for inter-procedural things (ABI things
> or similar). It sounds like the actual problem this code wants to tackle is
> one of those things, but instead it uses a heavy hammer?
This adjustment was added since target attribute/pragma support
(r0-104781-gfd438373cdd2a5), Mike may have more insightful comments on this.
According to the comments around, it aims to avoid the error message when users
specify a target attribute like cpu=power7 while the command line is being
specified like -m32 -mcpu=power6 etc. Without this adjustment, the following
check will raise error "target attribute or pragma changes AltiVec ABI".
if (TARGET_ELF)
{
if (!OPTION_SET_P (rs6000_altivec_abi)
&& (TARGET_64BIT || TARGET_ALTIVEC || TARGET_VSX))
{
if (main_target_opt != NULL &&
!main_target_opt->x_rs6000_altivec_abi)
error ("target attribute or pragma changes AltiVec ABI");
else
rs6000_altivec_abi = 1;
}
}
This adjustment silently disable this as it mask off altivec and vsx when they
are not explicitly specified.
(In reply to Peter Bergner from comment #4)
> (In reply to Kewen Lin from comment #2)
>
> > + /* Don't mask off ALTIVEC if it is enabled by an explicit VSX. */
> > + if (!TARGET_VSX || !(rs6000_isa_flags_explicit & OPTION_MASK_VSX))
>
> TARGET_VSX is only true here if it was explictly used, so I think you can
> drop the "|| !(rs6000_isa_flags_explicit & OPTION_MASK_VSX)" part of this
> test.
Good point, will adjust it accordingly.
> That said, how does your patch handle the following test case?
>
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
> return 0;
> }
>
> ...currently, this compiles with with no error or warning message which
> seems wrong to me.
Good finding, but it is an separated issue, it shows one bug in our target
attribute handling, filed PR115713.
