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 E513D3858D37 for ; Wed, 28 Sep 2022 21:31:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E513D3858D37 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 28SLUpMQ023611; Wed, 28 Sep 2022 16:30:51 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 28SLUoRf023610; Wed, 28 Sep 2022 16:30:50 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 28 Sep 2022 16:30:49 -0500 From: Segher Boessenkool To: Iain Sandoe Cc: "Kewen.Lin" , GCC Patches Subject: Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680] Message-ID: <20220928213049.GU25951@gate.crashing.org> References: <9d9f1f43-b528-387d-45a7-1d89400de0fc@linux.ibm.com> <5B4DCBBB-3237-4A9F-ACCA-6669DE6905B8@sandoe.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B4DCBBB-3237-4A9F-ACCA-6669DE6905B8@sandoe.co.uk> 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 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: Hi! On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote: > > On 28 Sep 2022, at 07:37, Iain Sandoe wrote: > >> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches wrote: > >> PR106680 shows that -m32 -mpowerpc64 is different from > >> -mpowerpc64 -m32, this is determined by the way how we > >> handle option powerpc64 in rs6000_handle_option. > >> > >> Segher pointed out this difference should be taken as > >> a bug and we should ensure that option powerpc64 is > >> independent of -m32/-m64. So this patch removes the > >> handlings in rs6000_handle_option and add some necessary > >> supports in rs6000_option_override_internal instead. > >> > >> With this patch, if users specify -m{no-,}powerpc64, the > >> specified value is honoured, otherwise, for 64bit it > >> always enables OPTION_MASK_POWERPC64 while for 32bit > >> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64. It probably shouldn't have to disable it, it can only be on if it is explicitly enabled by the user? So warning would be much better than implicitly disabling it. > Perhaps a small exposition on the target: > > powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 32b kernel, but the OS supports 64b processes on suitable hardware Just like Linux was before there was powerpc64-linux. I think it should still work even? > (and the OS does preserve the upper bits of 64b regs in the context). That works on Linux as well. What still does not work is user-mode context switches in 32-bit processes (so setjmp and getcontext stuff). > Of course, powerpc-darwin is not a blocker for anything, it should not hold you up (but sometimes it > manages to find a glitch missed elsewhere). It is stage 1, nothing blocks nothing :-) But indeed this looks like a bug not specific to Darwin. It would be nice if it was fixed before this goes in. > I will try to take a look at this this evening see if I can throw > any more light on it. Thanks! Segher