Re: solaris build problem with Sun compilers - Mailing list 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@rentec.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