On 03/12/2018 06:50 PM, Jakub Jelinek wrote: > On Mon, Mar 12, 2018 at 06:42:15PM +0100, Andreas Krebbel wrote: >> On 03/12/2018 06:31 PM, Jakub Jelinek wrote: >>> On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote: >>>> Currently the default ABI option for a GCC built on a 64 bit system is >>>> always -m64. This is inconvenient when e.g. building 32 bit libraries >>>> on a 64 bit system. The usual way to do this is to set the personality >>>> to s390 (32 bit) and let the configure script do the right thing. >>>> Having a GCC which defaults to -m64 also requires to get a -m31 somehow >>>> into the option list. >>>> >>>> With that patch the GCC driver checks the current personality setting in >>>> order to figure out at runtime what the default is supposed to be. >>>> >>>> Bootstrapped and regtested on s390x. >>>> >>>> I will commit the patch after waiting a few days for comments. >>> >>> I don't like this, it is inconsistent with how it is handled on all other >>> targets and how it worked for years. Having setarch magically change the >>> default is dangerous. >> >> Wow, that was quick ;) >> >> I didn't expect this to break things. Could you please elaborate where this >> might cause trouble? > > It is an unexpected major behavior change for environments that are this way > used for 1-2 decades.
Ok. I agree that changing the behavior unconditionally probably isn't a good idea. The default-default should stay as is. I'll try to hide this behind a configure switch. > When people want -m32 they just specify it, or if > they want a compiler that defaults to -m32 they configure it that way; > when gcc 7.x works one way and 8.x works differently, it will just mean > people will need to use -m32 or -m64 all the time, otherwise they won't be > sure what will happen. The only case I see where an additional -m option would be required is when trying to generate 64 bit code while running in a 32 bit setarch. Should this be something to care about? Leaving history aside don't you agree that it would have been more sensible to require a -m option only if you want to build for an ABI different from what is currently mandated by the personality setting? > Plus as I said, it is about consistency, why should s390x work in this > regard any differently in this regard from x86_64, powerpc64, sparc64, > mips64, which don't change the default even when setarch changes uname. Perhaps other platforms might want that as well?! ;) Background of that change is that while 32 bit support is starting to fade out of the distros we internally have to continue to build 32 bit stuff for a while. Currently the RPM spec files from the distros take care of supporting 32 bit builds in 64 bit environments. E.g. for the Glibc Fedora spec file I recently did send a patch adding -m31 to the compile options depending on the personality setting. The spec file already did that for many other biarch architectures. With biarch builds probably getting less attention in the future the GCC mechanism provides us with a simple way to do 32 bit builds for libs which used to support s390-32bit before but don't add -m31 depending on the current personality. It is especially annoying on S/390 with our -m31 switch (instead of -m32). This certainly wasn't a great choice in the very beginning of the S/390 port. I never dared to also support -m32 expecting that this would make the whole thing even more messy. Andreas > > Jakub >
