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) Call-saved registers are not guaranteed to preserve the entire 64 bits, but rs6000_hard_regno_call_part_clobbered takes care of setting the expectations correctly, so the intent seems to be for it to work. > I'm not sure why atm we don't > see that happening on Linux when compiling with -m32. It's OS_MISSING_POWERPC64 AFAICT. rs6000_option_override_internal tests for it and clears the POWERPC64 bit from the mask if it's not explicitly requested and the macro is nonzero. linux.h and linux64.h define it, the former as a nonzero constant, the latter as !TARGET_64BIT. Various other headers for powerpc operating systems define it as well. > I think if we fix this bug, then we won't need to modify the test cases > as you're doing here. *nod*. I remain unconvinced enabling it is a bug, though; at this point it's more like a feature, and dropping such a long-standing potentially-useful feature seems undesirable to me. But if that's just me, well, I could live with that ;-) I can see that it would make sense to only enable it if explicitly requested. Please let me know what you maintainers decide, and I'll adjust as needed. Thanks, -- 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!
