On 4/15/25 9:36 AM, Peter Bergner wrote: > On 4/15/25 12:01 AM, Alexandre Oliva wrote: >> On Apr 14, 2025, Peter Bergner <berg...@linux.ibm.com> wrote: >> >>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles. >> >> Oh, is that so? It seems to have been the case for quite a long time. >> I can trivially see that GCC 9 already did that, but it may have been >> around for much longer than that. >> >> And TBH it seemed sensible to me: if the selected CPU has 64-bit >> registers and instructions that use them, why not use them, even when >> using a 32-bit ABI? (when one controls the whole system, that is) > > To be pedantic, -m32 -mno-powerpc64 and -m32 -mpowerpc64 are different ABIs. > The question is, what ABI does the powerpc-elf target use? The same 32-bit > ABI as powerpc-linux? If so, that would require not enabling -mpowerpc64 > by default for -m32 compiles. > > You have to be careful using -m32 -mpowerpc64, as that is a specialized > use case. You have to know that the kernel you are running on saves and > restores the full 64-bit register on context switches. The 32-bit signal > contexts will not contain any of the upper 32-bits of the GPR regs. > Even calling a library function could corrupt the top part of the > callee-saved GPR regs if that library (eg, glibc) is compiled with > -m32 -mno-powerpc64. > > So what ABI does powerpc-elf use and what does it mandate?
It seems the behavior to add OPTION_MASK_POWERPC64 happened with Kewen's patch and rtems noticed the same thing you're seeing that OPTION_MASK_POWERPC64 is being enabled. maybe you need the same fix rtmes added? https://gcc.gnu.org/PR106680 Peter
