Bug 58833 - RFE: 64-bit native compiler on Solaris
Summary: RFE: 64-bit native compiler on Solaris
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.8.3
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-22 01:41 UTC by Stefan Teleman
Modified: 2014-02-22 08:47 UTC (History)
3 users (show)

See Also:
Host: i386-pc-solaris2.11, sparc-sun-solaris2.11
Target: x86_64-pc-solaris2.11, sparc64-sun-solaris2.11
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-10-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Teleman 2013-10-22 01:41:22 UTC
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
Comment 1 Eric Botcazou 2013-10-22 08:21:09 UTC
> 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.
Comment 2 Stefan Teleman 2013-10-22 13:06:14 UTC
Hi Eric,

Thank you very much for answering so quickly!

--Stefan
Comment 3 ro@CeBiTec.Uni-Bielefeld.DE 2013-10-24 13:10:01 UTC
> --- 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
Comment 4 Eric Botcazou 2014-02-22 08:47:45 UTC
.