On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
> with -maltivec -msoft-float. It does not use the FPRs, and it does use
> the VMX registers and VMX instructions.
Well color me surprised!
>> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
>
> That macro returns 1 on OSes that do not properly support -mpowerpc64.
Right, but haven't the 64-bit Linux kernels been fixed forever to always
save/restore the full 64-bit hardware registers on a context switch/signal?
If not, them this whole thing is moot and the current behavior of disabling
-mpower64 if we use -m32 later on the command line is the correct thing to do.
> But we should not enable -mpowerpc64 on 32-bit Linux by default.
I didn't imply we should do that. I was only agreeing with you that
we should try not disabling an explicit -mpowerpc64 when -m32 is used
later on the command line.
I only meant to say is that the code in rs6000_option_override_internal() is
what
seems to remove the OPTION_MASK_POWERPC64 from our cpu mask when -m32 is used
later on the command line... and that is controlled by OS_MISSING_POWERPC64.
Changing OS_MISSING_POWERPC64 as I mentioned would not add OPTION_MASK_POWERPC64
to our cpu masks when -m32 is used.
Peter
