Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> 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?

The kernel has.  But there are user space things (glibc) that haven't
been fixed, and those are default as well.

> 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.

The kernel has no way of disabling -mpowerpc64.  The instructions are
valid on any CPU that supports them, whether SF=1 or SF=0.

> > 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.

Okay, glad we agree :-)

> 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.

This is the default mask only here.

> Changing OS_MISSING_POWERPC64 as I mentioned would not add OPTION_MASK_POWERPC64
> to our cpu masks when -m32 is used.

So you say this is where the bug is?


Segher