Call for compiler help/advice: atomic builtins for v3

[Richard Guenther]

On 11/7/05, Paolo Carlini <pcarlini@suse.de> wrote:
> Richard Henderson wrote:
>
> >Actually, no, it's not possible.  At least in the context we're
> >discussing here.  Consider:
> >
> >One part of the application (say, libstdc++) is compiled with only
> >i386 support.  Here we wind up relying on a mutex to protect the
> >memory update.  Another part of the application (say, the exe) is
> >compiled with i686 support, and so chooses to use atomic operations.
> >The application will now fail because not all updates to the memory
> >location are protected by the mutex.
> >
> >
> Richard, sorry, I don't agree, on second thought. You are not
> considering that the idea is using a "smart" libgcc, a la glibc, as per
> Mark and Uli messages.
>
> A "libstdc++ compiled with only i386 support" what is it? It is a
> libstdc++ which at run time will call into libgcc, it has nothing
> inline. Then libgcc will use the best the machine has available, that
> is, certainly atomic operations, if the exe (compiled with -march=i686)
> can possibly run.
>
> In short, the keys are:
> 1- The "smart" libgcc, which always makes available the best the machine.
> 2- Mutexes cannot be inline, only atomic operations can.

Richard is right - it's enough that the inlined version doesn't agree with
whatever smartness is in libgcc.  But I also don't understand Richards
suggestion -- it basically means you decide at libstdc++ compile-time,
whether you can run on i386 or not.  This is of course ok for 99.99% of
all cases (distribution vendors supporting only i486+ anyway), but still
does not support changing the decision at application compile-time.
Note that in this particular case of atomic operations I can care less
about i386... ;)

Richard.