David Chisnall wrote:
> I think it's important to work out why it is failing on your machine.
> The reason I suggested this change is that, for me, looking at the
> assembly, it generates the same code as our inline asm on x86 but also
> works on non-x86 platforms that we currently use a painfully
Am Montag, den 04.05.2009, 22:07 +0200 schrieb Fred Kiefer:
> > I think the way to move forward is to add a configure option/test which
> > would fallback to a more portable yet less efficient implementation.
> >
> Yes, but what would be the condition to test for and what would be the
> correct b
Hi Fred,
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
Hi Everyone,
I'm currently working on adding exception handling support to clang,
but coming across some problems trying to understand the (completely
undocumented) ABI. It isn't quite the same as the NeXT/Apple ABI, so
I am wondering if anyone has any documentation about how it is
suppo
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 follo
