gnustep-dev
[Top][All Lists]
Advanced

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

Re: Small change in NSObject.m ASM needed for PowerPC build


From: Fred Kiefer
Subject: Re: Small change in NSObject.m ASM needed for PowerPC build
Date: Sat, 02 May 2009 23:16:00 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Using this change with gcc 4.3.2 on OpenSuse 11.1 give the following error:

Linking tool autogsdoc ...
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_sub_4'
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_add_4'

We either need to link another library or convince gcc that this is
really a build in function.

Fred


David Chisnall wrote:
> Ooops, this one is my fault.
> 
> Recent versions of GCC (and llvm-gcc / clang) support portable atomic
> intrinsics.  I've checked these on x86 and x86-64, and they generate the
> same code that my inline asm uses.  If you add this after the Windows
> bit (it will probably work on Windows too, but I'm not completely sure)
> then we will gain fast atomic  operations on all platforms (e.g. SPARC /
> ARM) that support them when compiling with a recent compiler.
> 
> David
> 
> #elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
> /* Use the GCC atomic operations with recent GCC versions */
> 
> typedef int32_t volatile *gsatomic_t;
> #define GSATOMICREAD(X) (*(X))
> #define GSAtomicIncrement(X)    __sync_fetch_and_add(X, 1)
> #define GSAtomicDecrement(X)    __sync_fetch_and_sub(X, 1)
> 
> 
> On 13 Apr 2009, at 10:19, Eric Wasylishen wrote:
> 
>> Hi,
>> I ran in to a small problem when compiling GNUstep (svn trunk) on
>> Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
>>
>> Compiling file NSObject.m ...
>> /tmp/ccF8zgwE.s: Assembler messages:
>> /tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
>> make[3]: *** [obj/NSObject.m.o] Error 1
>>
>> The PPC atomic increment and decrement functions starting at line 254
>> of NSObject.m both use the label 'modified:' in their asm code. I
>> found that by changing the labels in one of the functions to something
>> else ("modified2"), this error disappeared.
>>
>> I'm not sure if GCC is correct in reporting this as an error or not,
>> but it's easy to fix.
>> -Eric
>>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]