Re: notes on current atomics config and usage

[Benjamin Kosnik <bkoz at redhat dot com>]

> Indeed, I agree it's a nice idea. I'm only wondering whether the check 
> itself, in acinclude.m4 could be a little simpler, taking inspiration 
> from libgomp... Or the additional complexity is related to the annoying 
> i386  (vs i486 and newer) thing?!?

Yes, this config was messed up. I'm still working on a better way to do this...

Thanks for the libgomp pointer.

Turns out the only builtin used is __sync_fetch_and_add. But, even with
-march=i386, a builtin is used here:

int main()
{
  // NB: _Atomic_word not necessarily int. 
  typedef int atomic_type;
  atomic_type c1;
  atomic_type c2;
  __sync_fetch_and_add(&c1, c2);
 return 0;
}

?

> >In theory, this really does penalize every other non-x86 linux
> >platform, however.
> >  
> >
> Well, that's not true: indeed, when  _GLIBCXX_HAVE_ATOMIC_BUILTINS is 
> defined we *do* inline the calls (for powerpc, ia64, s390, alpha). As a 
> matter of fact, I introduced the
> _GLIBCXX_ATOMIC_BUILTINS macro for this very purpose...

Ah yes. I didn't realize that everything was going through *_dispatch
now: nice.

Still though, I think there is room for improvement here: it would be
nice to figure out a way for so_7 where __exchange_and_add and
__atomic_add don't have to be exported when the builtins are being used.

Oh, I wish there was a compile-time way to do something like
__gthread_active_p. Then we could unroll a lot of conditionals....
avoid a bunch of branching... Anyway. It seems like a link-test a la
__gthread_active_p is fundamentally at odds with a compile time test
that we can use do to cool template tricks.

Bummer.

-benjamin