RE: OT: sparc, sparcv9, & sparc64 [Was: What about sparcv9-linux as target for configure?]

[Christian Jönsson <christian at j-son dot org>]

Sorry, it wasn't my intention to whine, thank you for your
clarification.

Cheers,

/ChJ

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Robert Schiele
Sent: Thursday, September 12, 2002 9:29 PM
To: gcc
Subject: Re: OT: sparc, sparcv9, & sparc64 [Was: What about
sparcv9-linux as target for configure?]


On Thu, Sep 12, 2002 at 07:33:29PM +0200, Christian Jönsson wrote:
> uhm, I'm actually a bit confused here... as I understand it, and right

> now it seems I understand this wrong, is that 'sparc' is the same as 
> sparcv7 actually with for example sun4c (any more?). now, there would 
> naturally be a sparcv8 also perhaps (like sun4d and sun4m) and there 
> is the sparcv9 like the sun4u. Now, where does sparc64 come in? are we

> saying sparc64 *is* sparcv9? nah... then sparc32 would be sun4{c,d,m},

> right?
> 
> and, looking at how redhat/rawhide/aurora sets it's compier options:
> 
> optflags: sparc -O2 -m32 -mtune=ultrasparc
> optflags: sparcv9 -O2 -m32 -mcpu=ultrasparc
> optflags: sparc64 -O2 -m64 -mcpu=ultrasparc
> 
> I'd say sparc64 and sparcv9 is not the same...
> 
> and btw aurora's suggestion to have
> 
> optflags: sparcv8 -O2 -m32 -mcpu=v8 -mtune=ultrasparc
> 
> is perhaps coming also (mainly for multiplication heavy stuff like 
> openssl and glibc or rather libm there).

I know that this is not consistent in all places.  I also know that rpm
uses these aliases vor compiler setup.  But I also know---and you should
consider that---that within Solaris a 64 bit compiler is built, when you
configure with sparcv9.  There was a discussion about changing this to
32 bit on this list once.  It was even changed for a short period of
time.  But finally a decision was made to put this back to 64 bit.

And a fact is that only gcc for Solaris accepts sparcv9, where this is
the same as sparc64.

So you have multiple options:

- You could whine about the current situation.

- You could improve it by providing a patch that implements a better
  commonly accepted solution.

- You could be pragmatic and just configure with sparc64 if you want a
  64 bit compiler and build with just sparc for a 32 bit compiler and
  setup the optimization with -mcpu=ultrasparc.

Robert

-- 
Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de