On Apr 15, 2025, Peter Bergner <berg...@linux.ibm.com> wrote: > On 4/15/25 9:36 AM, Peter Bergner wrote: >> So what ABI does powerpc-elf use and what does it mandate?
That's not for me to decide, but to me the patch that introduced OS_MISSING_POWERPC64 and the PR106680 coversation suggests that enabling -mpowerpc64 with -m32 -mcpu=<64bitcapable> had long been intended, *except* on systems that are not 64-bit-compatible when running 32-bit mode programs. I acknowledge it is a different ABI, but since call-saved registers are handled in a way that makes the difference irrelevant, a system without preemption (including interrupts and traps) would hit no trouble AFAICT. Since powerpc-elf doesn't assume an underlying operating system, it doesn't strike me as an unreasonable assumption that there won't be preemption, or that, if the initialization code enables execution of powerpc64 instructions (I'd expect that to be necessary to enable them, but that's just an uncheckedd guess), then one could also count on 64-bit register saves at traps, interrupts, and context switches; as long as there isn't something like async signals, that should suffice to make -mpowerpc64 safe, useful and desirable in this target. But I acknowledge that it's a bit of a risky proposition; I suppose it would be more conservative to disable it uniformly on all targets, and only enable it with -m32 when explicitly requested. I.e., make OS_MISSING_POWERPC64 the rule rather than the exception, and define it to zero on targets where it is deemed safe. I'm not sure what the setting should be for powerpc-elf. Since !OS_MISSING_POWERPC64 has been in effect for so long on it, my inclination would be to leave it as is. > It seems the behavior to add OPTION_MASK_POWERPC64 happened with > Kewen's patch No, it had been there *long* before, Kewen's patch only enabled systems that would misbehave due to ABI concerns to declare the effective incompatibility of enabling -mpowerpc64 in -m32. IMHO it should be a lot noisier than it is, possibly an error, when the incompatibility is there, since any async interaction could be trouble. > maybe you need the same fix rtmes added? I don't see reason to consider that a fix for powerpc-elf; it would be a feature regression for those who take legitimate advantage of 64-bit registers and instructions on deployed hardware. But my considerations about its not being a conservatively safe feature apply: I wouldn't stand in the way of flipping the global default, and *not* enabling -mpowerpc64 implicitly any more on powerpc-elf, provided that it *could* still be enabled when knowledge about the target environment makes it safe. > https://gcc.gnu.org/PR106680 -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity. Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
