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

Re: solaris build problem with Sun compilers

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

In response to

pgsql-ports by date

Next:From: Bruce MomjianDate: 2006-05-18 16:02:55
Subject: Re: solaris build problem with Sun compilers
Previous:From: Alan StangeDate: 2006-05-18 12:40:36
Subject: Re: solaris build problem with Sun compilers

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