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

Re: solaris build problem with Sun compilers

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Alan Stange <stange(at)rentec(dot)com>
Cc: 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-17 22:39:48
Message-ID: 200605172239.k4HMdm303324@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
Alan Stange wrote:
> Tom Lane wrote:
> > Alan Stange <stange(at)rentec(dot)com> writes:
> >   
> >> Check out the comment and implementation for cas32() in this .il 
> >> template file for libc from OpenSolaris:
> >>     
> >
> >   
> >> http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/sparc/threads/sparc.il
> >>     
> >
> > If you mean
> >
> >           * When compiling with -xarch=v8, the compiler refuses to
> >           * accept the 'cas' instruction, so we encode it in hex below.
> >
> > I can't say that that impresses me.  It still will fail on v8 chips no?
> > What's the point of fooling the compiler if you can't fool the hardware?
> 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.

Uh, are you saying our Solaris Sparc "cas" ASM is only going to work for
Solaris 11 tools?  That doesn't sound good.  We must have people using
earlier Solaris tools.

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-ports by date

Next:From: Bruce MomjianDate: 2006-05-17 23:55:35
Subject: Re: solaris build problem with Sun compilers
Previous:From: Bruce MomjianDate: 2006-05-15 17:26:09
Subject: Re: [HACKERS] Compiling on 8.1.3 on Openserver 5.05

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