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 2A87B3851145 for ; Wed, 31 Aug 2022 19:29:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2A87B3851145 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 27VJSdR9012053; Wed, 31 Aug 2022 14:28:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 27VJSdKQ012052; Wed, 31 Aug 2022 14:28:39 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 31 Aug 2022 14:28:39 -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: <20220831192839.GT25951@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16dc8d80-44d5-b739-b4a8-d02a01943d49@linux.ibm.com> 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 12:00:14PM -0500, Peter Bergner wrote: > On 8/31/22 11:05 AM, Segher Boessenkool wrote: > > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote: > >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc. > > > > Oh? Why should it disable -maltivec? -mvsx makes a little sense on > > one hand, but totally none on the other either. > > VSX has to be disabled, since VSX replies on the FP registers existing. It doesn't? On a CPU supporting VSX the FP registers are overlaid on the VSX registers, not the other way around. GCC says cc1: warning: '-mvsx' requires hardware floating point and that's okay with me of course, but it doesn't say why it is required. Implementation convenience coupled with lack of a use case is my best guess :-) OTOH VMX and hard float are completely orthogonal (the VMX FP things do not even use the fpscr for example). > As for Altivec, I'm pretty sure there are some inherent dependencies > there, probably both in hardware and our GCC backend implementation. > I could be wrong, but my guess is things will fall over the ground > if as allow -maltivec along with -msoft-float. Does the linux kernel > only build with -msoft-float assuming it disables altivec and vsx? > Or does it explicitly always also add -mno-altivec? 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. > So in linux*.h, we have the following which came from a 2004 commit from Alan: > > linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT That macro returns 1 on OSes that do not properly support -mpowerpc64. > ...so I think there was no real reason, other than old 64-bit linux kernels didn't > save the upper register state in 32-bit mode binaries. And it is still not saved in 32-bit user mode (setjmp/longjmp and getcontext/setcontext). Most bigger programs will fail, and most smaller programs (including everything in the GCC testsuite) work fine. But we should not enable -mpowerpc64 on 32-bit Linux by default. Segher