This is much more of a RFE than a bug (defect). Would it be possible for GCC in Solaris to auto-configure itself as a 64-bit native compiler by default (instead of the current 32-bit native compiler default)? The output of `uname -p` in Solaris is always 'i386' or 'sparc', regardless of whether or not the kernel is 32-bit or 64-bit. In Solaris 11 and later, kernels are 64-bit only, so the output of `uname -p` does not really reflect reality. One way of working around this `uname -p` limitation in Solaris is to use the first string token in the output of `isainfo`, which is: 'amd64 i386' (on Intel) 'sparcv9 sparc' (on SPARC) I realize that 'isainfo' is not a Standard UNIX command, and that the suggestion of using 'isainfo' instead of `uname -p` is very Solaris-specific (and likely non-portable). Again, this is just a RFE. Thank you very much! --Stefan
> Would it be possible for GCC in Solaris to auto-configure itself as a 64-bit > native compiler by default (instead of the current 32-bit native compiler > default)? The decision was made years ago not to do so, at least on SPARC, because the 64-bit compiler was measurably slower than the 32-bit compiler. > The output of `uname -p` in Solaris is always 'i386' or 'sparc', regardless > of whether or not the kernel is 32-bit or 64-bit. In Solaris 11 and later, > kernels are 64-bit only, so the output of `uname -p` does not really reflect > reality. Given that the 32-bit compiler is biarch by default, at least on SPARC, I'm not sure there is really an incentive for switching to 64-bit by default.
Hi Eric, Thank you very much for answering so quickly! --Stefan
> --- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- >> Would it be possible for GCC in Solaris to auto-configure itself as a 64-bit >> native compiler by default (instead of the current 32-bit native compiler >> default)? > > The decision was made years ago not to do so, at least on SPARC, because the > 64-bit compiler was measurably slower than the 32-bit compiler. That's my experience as well, both on SPARC and x86. When some users loudly clamored for a 64-bit-default Solaris/x86 configuration, one argument was that a 64-bit gcc would be faster due to a larger register set. My experience is just the opposite: a amd64-pc-solaris2.11 bootstrap is considerably slower that i386-pc-solaris2.11. I've not even started investigating in detail, so this is just one data point. >> The output of `uname -p` in Solaris is always 'i386' or 'sparc', regardless >> of whether or not the kernel is 32-bit or 64-bit. In Solaris 11 and later, >> kernels are 64-bit only, so the output of `uname -p` does not really reflect >> reality. > > Given that the 32-bit compiler is biarch by default, at least on SPARC, I'm not > sure there is really an incentive for switching to 64-bit by default. Agreed: on the opposite, I see a number of counter arguments: * Studio (at least until the current 12.3) defaults to 32-bit. Why would gcc be different on just one OS version? * I think the user experience would be terrible: consider a user who used to work on Solaris 10 with gcc x.y. Now he switches to Solaris 11, rebuilds gcc x.y and suddenly all his objects are 64-bit, with nothing else changed. He has to modify his build environment to retain interoperability with his existing objects and libraries. Not exactly what I'd call seamless. Given all this, I think users who really need (or think they need) a 64-bit-default gcc on Solaris can get it today, but the default should remain 32-bit. Rainer
.