64 bit gcc?

64 bit gcc?

[John Young]

Sorry if this is the wrong place to ask this, but I
am not sure where to go...

I was trying to build pidentd and got the message:

configure: error: 

ERROR: gcc doesn't support 64-bit compilation on 'sparc-sun-solaris2.8'
yet.
       Please read the INSTALL file for more information.

INSTALL says:
* Some information for Solaris 7 users:

If you want to run pidentd on a 64-bit kernel, you need to compile with
a
compiler capabable of producing 64-bit binaries.  Both gcc 2.8.1 and
egcs
1.1 cannot do this, so you need to use SunPro C 5.0.

Is this planned for a future release of gcc?

						JY
------------------------------------------------------------
John E. Young				    B1148/R202
Analytical Services and Materials           864-8659

Re: 64 bit gcc?

[Janis Johnson]

On Wed, Oct 17, 2001 at 11:09:32AM -0400, Thomas R. Stevenson wrote:
>
>
> I'm trying to create a 64-bit version of gcc (3.0.1) for a SunBlade
> 100 with Solaris 8.
>
> I've tried using sparc64-sun-solaris2.8 and sparcv9-sun-solaris2.8.
> The "configuration" script complains about sparc64-sun-solaris2.8, and
> the "make bootstrap" command fails with the following errors:
> ...
> Am I doing something wrong, or can't I create a 64-bit version of gcc
> (3.0.1) for solaris 8 on a SunBlade 100?

and

On Thu, Oct 18, 2001 at 11:24:42AM -0400, John Young wrote:
> Sorry if this is the wrong place to ask this, but I
> am not sure where to go...
>
> I was trying to build pidentd and got the message:
>
> configure: error:
>
> ERROR: gcc doesn't support 64-bit compilation on 'sparc-sun-solaris2.8'
> yet.
>        Please read the INSTALL file for more information.
>
> INSTALL says:
> * Some information for Solaris 7 users:
>
> If you want to run pidentd on a 64-bit kernel, you need to compile with a
> compiler capabable of producing 64-bit binaries.  Both gcc 2.8.1 and egcs
> 1.1 cannot do this, so you need to use SunPro C 5.0.
>
> Is this planned for a future release of gcc?

The question of whether GCC supports 64-bit binaries on sparc comes up
quite frequently.  Recently the following text was added to the
"Host/Target Specific Installation Notes" for GCC 3.0:

  sparc-sun-solaris2*

  Starting with Solaris 7, the operating system is capable of executing
  64-bit SPARC V9 binaries.  GCC 3.0 doesn't properly support this yet.
  Although some patches or recipes to enable this support have been posted
  to various newsgroups and mailing lists, we recommend against using
  them, since the compiler may either crash or, worse, silently generate
  bad code.  If you really need this capability now, you might try a CVS
  version of GCC 3.1, which will fully support this.  If all you want is
  code tuned for the UltraSPARC CPU, you should try the
  -mtune=ultrasparc option instead, which should be safe from
  those bugs and produce code that, unlike full 64-bit code, can still run
  on non-UltraSPARC machines.

Those notes also include, for both 3.0 and the CVS mainline (and probably
for 2.95, but I haven't looked there):

  sparc64-*-*

  GCC version 2.95 is not able to compile code correctly for
  sparc64 targets.  Users of the Linux kernel, at least,
  can use the sparc32 program to start up a new shell
  invocation with an environment that causes configure to
  recognize (via uname -a) the system as sparc-*-* instead.

The new text in the 3.0 installation instructions would be useful to
have in the mainline version as well, since that is the one that is
accessible from the GCC web site and is more likely to be read.

Would it be helpful if the build status lists for GCC 3.0 and 2.95
listed a few would-be popular targets that are explicitly not
supported?

Tom and John, where could we have put this information so that you
could have found it easily?

Janis

Re: 64 bit gcc?

[Gerald Pfeifer]

On Thu, 18 Oct 2001, Janis Johnson wrote:
> The new text in the 3.0 installation instructions would be useful to
> have in the mainline version as well, since that is the one that is
> accessible from the GCC web site and is more likely to be read.

Good idea. Approved.

> Would it be helpful if the build status lists for GCC 3.0 and 2.95
> listed a few would-be popular targets that are explicitly not
> supported?

Excellent idea. Approved. ;-)

Gerald

Re: 64 bit gcc?

[Alex Zhukov]

Hi all!

Few weeks ago I have compiled gcc(c c++ ...) v3.0.1 for 
sparcv9-sun-solaris2.8 and it works just _perfect_ for me with Sun's binutils 
(if one can call the as ar nm ld etc. this way).
#file `which gcc` 
reports this:
> /usr/local/bin/gcc:     ELF 64-bit MSB executable SPARCV9 Version 1, 
dynamically linked, not stripped

 As a test I did full recompile of grep, gawk, mc, apache and few other 
widely used progs, all they work just fine. 
NOTE: I look through the the gcc mailing not very often, so I may have missed 
something, but I still dont see any problem using the _standard gcc 3.0.1 on 
sparcv9-sun-solaris2.8.  


On Thursday 18 October 2001 22:50, Janis Johnson wrote:
> On Wed, Oct 17, 2001 at 11:09:32AM -0400, Thomas R. Stevenson wrote:
> > I'm trying to create a 64-bit version of gcc (3.0.1) for a SunBlade
> > 100 with Solaris 8.
> >
> > I've tried using sparc64-sun-solaris2.8 and sparcv9-sun-solaris2.8.
> > The "configuration" script complains about sparc64-sun-solaris2.8, and
> > the "make bootstrap" command fails with the following errors:
> > ...
> > Am I doing something wrong, or can't I create a 64-bit version of gcc
> > (3.0.1) for solaris 8 on a SunBlade 100?
>
> and
>
> On Thu, Oct 18, 2001 at 11:24:42AM -0400, John Young wrote:
> > Sorry if this is the wrong place to ask this, but I
> > am not sure where to go...
> >
> > I was trying to build pidentd and got the message:
> >
> > configure: error:
> >
> > ERROR: gcc doesn't support 64-bit compilation on 'sparc-sun-solaris2.8'
> > yet.
> >        Please read the INSTALL file for more information.
> >
> > INSTALL says:
> > * Some information for Solaris 7 users:
> >
> > If you want to run pidentd on a 64-bit kernel, you need to compile with a
> > compiler capabable of producing 64-bit binaries.  Both gcc 2.8.1 and egcs
> > 1.1 cannot do this, so you need to use SunPro C 5.0.
> >
> > Is this planned for a future release of gcc?
>
> The question of whether GCC supports 64-bit binaries on sparc comes up
> quite frequently.  Recently the following text was added to the
> "Host/Target Specific Installation Notes" for GCC 3.0:
>
>   sparc-sun-solaris2*
>
>   Starting with Solaris 7, the operating system is capable of executing
>   64-bit SPARC V9 binaries.  GCC 3.0 doesn't properly support this yet.
>   Although some patches or recipes to enable this support have been posted
>   to various newsgroups and mailing lists, we recommend against using
>   them, since the compiler may either crash or, worse, silently generate
>   bad code.  If you really need this capability now, you might try a CVS
>   version of GCC 3.1, which will fully support this.  If all you want is
>   code tuned for the UltraSPARC CPU, you should try the
>   -mtune=ultrasparc option instead, which should be safe from
>   those bugs and produce code that, unlike full 64-bit code, can still run
>   on non-UltraSPARC machines.
>
> Those notes also include, for both 3.0 and the CVS mainline (and probably
> for 2.95, but I haven't looked there):
>
>   sparc64-*-*
>
>   GCC version 2.95 is not able to compile code correctly for
>   sparc64 targets.  Users of the Linux kernel, at least,
>   can use the sparc32 program to start up a new shell
>   invocation with an environment that causes configure to
>   recognize (via uname -a) the system as sparc-*-* instead.
>
> The new text in the 3.0 installation instructions would be useful to
> have in the mainline version as well, since that is the one that is
> accessible from the GCC web site and is more likely to be read.
>
> Would it be helpful if the build status lists for GCC 3.0 and 2.95
> listed a few would-be popular targets that are explicitly not
> supported?
>
> Tom and John, where could we have put this information so that you
> could have found it easily?
>
> Janis

Re: 64 bit gcc?

[Jack Cummings]

On Mon, Oct 22, 2001 at 02:35:24AM +0300, Alex Zhukov wrote:
 
> Few weeks ago I have compiled gcc(c c++ ...) v3.0.1 for 
> sparcv9-sun-solaris2.8 and it works just _perfect_ for me with Sun's binutils 
> (if one can call the as ar nm ld etc. this way).
> #file `which gcc` 
> reports this:
> > /usr/local/bin/gcc:     ELF 64-bit MSB executable SPARCV9 Version 1, 
> dynamically linked, not stripped
 
>  As a test I did full recompile of grep, gawk, mc, apache and few other 
> widely used progs, all they work just fine. 
> NOTE: I look through the the gcc mailing not very often, so I may have missed 
> something, but I still dont see any problem using the _standard gcc 3.0.1 on 
> sparcv9-sun-solaris2.8.  

Hmm. I've compiled all that, and more, using gcc sparcv9-sun-solaris2.7. 

I noticed problems with:

perl-5.6.1 
gnome-libs-1.4.1.2

Which led me to believe that the people who maintain the compiler might 
know what they are talking about when they say it has problems. :)

--Jack 

Re: 64 bit gcc?

[Alex Zhukov]

> Hmm. I've compiled all that, and more, using gcc sparcv9-sun-solaris2.7.
>
> I noticed problems with:
>
> perl-5.6.1
> gnome-libs-1.4.1.2
>
> Which led me to believe that the people who maintain the compiler might
> know what they are talking about when they say it has problems. :)
>
> --Jack

Well, yes you're right! Frankly speaking openssl-0.9.x did not compile well 
for me until i supplied CC="gcc -m32" but everything else was just fine. 
As for the gnome-libs you have to be _absolutely_ sure you're using Sun's 
binutils(ar, as, ld etc.), otherwise it will segfault.

BTW, i saw your FAQ at ice.mudshark.org and i must say that on solaris2.7 i 
do have trouble compiling things and trouble running them, but not on 2.8. i 
have two completely same machines (ultrasparc2i) one of them running 2.7 and 
other one 2.8 on 2.8 everything is ok. 

Alex

Re: 64 bit gcc?

[Alexandre Oliva]

On Oct 21, 2001, Jack Cummings <jack@ice.mudshark.org> wrote:

> On Mon, Oct 22, 2001 at 02:35:24AM +0300, Alex Zhukov wrote:
>> Few weeks ago I have compiled gcc(c c++ ...) v3.0.1 for 
>> sparcv9-sun-solaris2.8 and it works just _perfect_ for me with Sun's binutils 
>> (if one can call the as ar nm ld etc. this way).
>> #file `which gcc` 
>> reports this:
>> > /usr/local/bin/gcc:     ELF 64-bit MSB executable SPARCV9 Version 1, 
>> dynamically linked, not stripped
 
>> As a test I did full recompile of grep, gawk, mc, apache and few other 
>> widely used progs, all they work just fine. 
>> NOTE: I look through the the gcc mailing not very often, so I may have missed 
>> something, but I still dont see any problem using the _standard gcc 3.0.1 on 
>> sparcv9-sun-solaris2.8.  

> Hmm. I've compiled all that, and more, using gcc sparcv9-sun-solaris2.7. 

> I noticed problems with:

> perl-5.6.1 
> gnome-libs-1.4.1.2

> Which led me to believe that the people who maintain the compiler might 
> know what they are talking about when they say it has problems. :)

The reason why GCC 3.0.x and earlier are regarded as not fully
supporting 64-bit sparc are two:

- sometimes, variables of type double are misaligned in the stack,
  such that if a load or store instruction that requires alignment to
  8 bytes boundaries is used, your program will crash with a SIGBUS

- infrastructure needed to fully represent the 64-bit sparc ABI was
  missing in GCC 3.0.x, even though it was already present as a patch
  in Red Hat's GCC 2.96.  It was deemed to risky for GCC 3.0, and was
  only merged into the GCC CVS tree after the 3.0 branch was created.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: 64 bit gcc?

[Jack Cummings]

On Sun, Nov 11, 2001 at 10:39:07PM -0200, Alexandre Oliva wrote:
 
> The reason why GCC 3.0.x and earlier are regarded as not fully
> supporting 64-bit sparc are two:
 
> - sometimes, variables of type double are misaligned in the stack,
>   such that if a load or store instruction that requires alignment to
>   8 bytes boundaries is used, your program will crash with a SIGBUS
 
> - infrastructure needed to fully represent the 64-bit sparc ABI was
>   missing in GCC 3.0.x, even though it was already present as a patch
>   in Red Hat's GCC 2.96.  It was deemed to risky for GCC 3.0, and was
>   only merged into the GCC CVS tree after the 3.0 branch was created.

Thanks for the explanation. 

I will look into 3.1. 

--Jack 

Re: 64 bit gcc?

[John Young]

------- Start of forwarded message -------
Date: Thu, 18 Oct 2001 13:30:40 -0700
From: Janis Johnson <janis187@us.ibm.com>
To: j.e.young@larc.nasa.gov
Subject: Re: 64 bit gcc?
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200110182002.f9IK2ud06294@mushu.larc.nasa.gov>; from jyoung@mushu.larc.nasa.gov on Thu, Oct 18, 2001 at 04:02:56PM -0400
Content-Length: 1039

John,

On Thu, Oct 18, 2001 at 04:02:56PM -0400, John Young wrote:
> 
>    Thanks for your response.  I had not yet installed gcc 3.0
> (mostly I am still running 2.95.2), and so did not have the notes.
> I went to the web page ( http://www.gnu.org/software/gcc/gcc.html )
> to see if I could find any mention of whether v3.x supported 64-bit
> but did not see any.  I also checked the FAQ, but (perhaps I am
> blind and should read it again) did not se it mentioned there
> either.  Being fairly busy, I did not want to configure/build/
> propagate a new version of gcc until I had a good reason to.
> 
>    Thanks again for the info..

Would you mind sending this to the gcc mailing list?  It would be
valuable if the people who maintain the installation instructions and
other documentation could know where you expected to find this kind of
information.  They want the documentation to be as useful as possible,
but the existing organization always seems intuitive to those who are
accustomed to it.

Thank you for your feedback.

Janis
------- End of forwarded message -------