Re: solaris build problem with Sun compilers

[Alan Stange <stange(at)rentec(dot)com>]

Theo Schlossnagle wrote:
> On May 17, 2006, at 8:04 PM, Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Alan Stange <stange(at)rentec(dot)com> writes:
> > > > > I believe the trick here is that Solaris 10 will only run on v9 
> > > > > hardware
> > > > > (or the sun4u systems), which all have the instruction.   But the 
> > > > > v8 ABI
> > > > > "model" doesn't have it.   So, in some sense the ABI doesn't "allow"
> > > > > this instruction, but the hardware does, so they can just slam it in
> > > > > knowing that it'll work.
> > > >
> > > > Well, that might be OK for Sun's compiler since they know what a given
> > > > version of Solaris will run on.  But I don't think we can adopt the 
> > > > same
> > > > attitude for our gcc code path; that has to work on Sparc-based Linuxen
> > > > and BSDen.  I don't think it's appropriate to kiss off support for v8
> > > > chips when we haven't seen any proof at all of a performance boost in
> > > > return.
> > > >
> > > > Maybe the right answer is to leave the code as-is, ie, deliberately not
> > > > the same for Sun and gcc compilers.
> > >
> > > OK, I have applied the following patch which documents that the Solaris
> > > CC TAS ASM only works for sparc9.  Hopefully either sparc8 is not needed
> > > (unlikely) or someone will fix it.  I have CC'ed the original
> > > contributor who added "cas".
> >
> > Oh, I just found this email that has a simplified sparc8 asm:
> >
> >     http://archives.postgresql.org/pgsql-ports/2006-05/msg00025.php
> >
> > Attached is the new solaris_sparc.s file with the #ifdef sparc8 test;
> > applied.
>
> I don't think that asm does what you think it does.  That hex encoding 
> of the cas instruction doesn't work on Sparcv8, only sparcv8plus.  The 
> reason that it is hacked that way is that, for other reasons, they can't 
> use the -xarch=v8plus flag (despite compiling on v8plus capable chips).  
> Basically that code hardcodes a v8plus instruction into a v8 binary 
> "knowing" that it will never run on a non-v8plus capable chip.  The 
> reason that they can do this is because they (as I understand it) open 
> solaris won't support any chips so old as to not run v8plus code.

I think that's what was written above...

> We shouldn't be suffering from that problem and -xarch=v8plus should be 
> used to produce 32-bit binaries and -xarch=v9 should be used to produce 
> 64-bit sparc binaries.  I can't think of a reason to every compile the 
> Postgres source with -xarch=v8 instead of -xarch=v8plus, the latter will 
> produce much better code overall.


linking the postgresql libpq with code compiled at v8 is the only reason 
that I can think of.   v8plus has been the default in the Sun compilers 
for some time now, so this would only be an issue for an older binary. 
 As far as I can tell, gcc still produces v7 code by default and knows 
nothing about v8plus.

Even better would be using v8plusb with the Sun compilers.

-- Alan