Hi!
On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 07:37, Iain Sandoe <i...@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
