[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to tell the compiler NOT to assume cpu provides atomic instructions



On Tue, 2011-03-08 at 02:03 +0000, brian m. carlson wrote:
> On Mon, Mar 07, 2011 at 07:54:13PM -0500, RR wrote:
> > checking whether the C compiler (gcc -pthread -I../..//include
> > -I/usr/include/libxml2 -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -g3 -mtune=ultrasparc -mcpu=v8 -fomit-frame-pointer
> > -O6    ) works                 ... yes
> > checking whether the C compiler (gcc -pthread -I../..//include
> > -I/usr/include/libxml2 -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -g3 -mtune=ultrasparc -mcpu=v8 -fomit-frame-pointer
> > -O6    ) is a                  cross-compiler... no
> 
> Okay.  I've pinpointed the problem.  If atomic intrinsics are used but
> not supported on the target architecture (variant), GCC will emit a link
> error for that function.
> 
> Your problem is -mcpu=v8.  v8 processors (AFAICT) do not support the
> intrinsics necessary.  Remove that option (or whatever is causing that
> option) and it should work.  It may be that for some reason configure
> thinks that 32-bit code should use -mcpu=v8, but that isn't the case.
> Debian's default configuration (without -mcpu and -mtune) should work
> just fine for you.
> 
FWIW... I've dug out my notes on atomic operations on SPARC.

1. SPARC V8 only has very weak atomic ops (IIRC it's only test and set)
which aren't sufficient to implement all of the GCC atomic built-ins
without some extra work.  This is why there will be a need to provide
your own implementation and a linking problem if you don't.

2. SPARC V9 has CAS which allows most of the GCC atomic ops to be
emulated but is 64 bit, which may not be what you want.

3. SPARC V8+ is the instruction set of the V9 processors running in 32
bit mode.  Thus it includes CAS and is 32 bit.

By default I think GCC still generates V8 code on Debian, setting
-mcpu=v8+ should do what you want.  Furthermore I might suggest using
Hans Boehm's libatomic-ops:

http://www.hpl.hp.com/research/linux/atomic_ops/
http://packages.debian.org/search?keywords=libatomic-ops

As it gets around a number of the unpleasent issues with memory
barriers.

HTH

Cheers,
 - Martin



Reply to: