From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
by sourceware.org (Postfix) with ESMTP id E513D3858D37
for <gcc-patches@gcc.gnu.org>; 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 <segher@kernel.crashing.org>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: "Kewen.Lin" <linkw@linux.ibm.com>, GCC Patches <gcc-patches@gcc.gnu.org>
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> <FCF2C93B-71A7-4AB1-800F-E9D127593DCA@sandoe.co.uk> <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: <gcc-patches.gcc.gnu.org>
Hi!
On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 07:37, Iain Sandoe <iain@sandoe.co.uk> wrote:
> >> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches <gcc-patches@gcc.gnu.org> 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