David, now this is very strange. Your tiny program works perfectly here, even when I change it into an Objective-C fragment. I get the expected ASM code (or even more so). And it gives the right result. So why is it failing in NSObject.m?
I ran this file through the preprocessor and get the following line: result = __sync_fetch_and_sub(((gsatomic_t)&(((obj)anObject)[-1].retained)), 1); This looks a bit complicated but quite sensible. Converting this into assembler gives .loc 1 380 0 movl 8(%ebp), %eax subl $8, %eax movl $1, 4(%esp) movl %eax, (%esp) call __sync_fetch_and_su...@plt movl %eax, -16(%ebp) Sorry, no clue what gcc is doing here. Next I tried to make your example more similar to the code above, resulting in this: #include <stdlib.h> typedef int32_t volatile *gsatomic_t; volatile int a; int main(void) { __sync_fetch_and_add((gsatomic_t)&a, 1); return a; } But that still compiles well. .file "sync1.m" .text .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx lock addl $1, a movl a, %eax popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .local _OBJC_SELECTOR_TABLE .comm _OBJC_SELECTOR_TABLE,8,4 .comm a,4,4 .ident "GCC: (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]" .section .comment.SUSE.OPTs,"MS",@progbits,1 .ascii "ospwg" .section .note.GNU-stack,"",@progbits Any idea, what I could test next? Fred David Chisnall wrote: > Can you try compiling this short C program: > > volatile int a; > int main(void) > { > __sync_fetch_and_add(&a, 1); > return a; > } > > For me, with GCC 4.2.1, this Just Works™. If it doesn't for you, can > you try compiling it with gcc -S and take a look at the generated .s > file? It should contain this short sequence: > > lock > addl $1, a > > If instead it contains: > > call __sync_fetch_and_add > > Then something weird is going on - the compiler is generating a call to > the implementation in libgcc_s, which should only be used for non-x86 > platforms. > > If we can't manage to get this working in the general case, then you can > use this little program in the configure script - if it runs and exits > then the compiler supports this extension (both recent gcc and clang do, > so it should become increasingly-well supported over time). > > I'm still surprised that it doesn't work for you - I've not had any > problems with it for a couple of years on FreeBSD, and I was under the > impression GCC supported Linux better than FreeBSD. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev