Skip site navigation (1) Skip section navigation (2)

Re: solaris build problem with Sun compilers

From: Theo Schlossnagle <jesus(at)omniti(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Theo Schlossnagle <jesus(at)omniti(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alan Stange <stange(at)rentec(dot)com>, pgsql-ports(at)postgresql(dot)org
Subject: Re: solaris build problem with Sun compilers
Date: 2006-05-18 00:21:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-ports
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:
> 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.

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.

// Theo Schlossnagle
// CTO --
// OmniTI Computer Consulting, Inc. --
// Ecelerity: Run with it.

In response to


pgsql-ports by date

Next:From: Bruce MomjianDate: 2006-05-18 00:30:52
Subject: Re: solaris build problem with Sun compilers
Previous:From: Bruce MomjianDate: 2006-05-18 00:07:03
Subject: Re: solaris build problem with Sun compilers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group