From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 0C3D3385800F for ; Wed, 31 Aug 2022 21:08:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C3D3385800F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 27VL7pPU015440; Wed, 31 Aug 2022 16:07:51 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 27VL7psU015439; Wed, 31 Aug 2022 16:07:51 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 31 Aug 2022 16:07:50 -0500 From: Segher Boessenkool To: Peter Bergner Cc: "Kewen.Lin" , GCC Patches , David Edelsohn Subject: Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680] Message-ID: <20220831210750.GV25951@gate.crashing.org> References: <69277846-f587-b79e-f741-a2942d326778@linux.ibm.com> <20220831152412.GP25951@gate.crashing.org> <20220831160529.GR25951@gate.crashing.org> <16dc8d80-44d5-b739-b4a8-d02a01943d49@linux.ibm.com> <20220831192839.GT25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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