Re: Call for compiler help/advice: atomic builtins for v3

[Paolo Carlini <pcarlini at suse dot de>]

Richard Henderson wrote:

>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.
>
>The use of a mutex (or not) is part of the API associated with the
>memory location.  If it's ever used by one part of the application,
>it must be used by all.
>  
>
Ok, I think I get this point: you cannot link together two parts of the
application "sharing" a memory location and protecting the accesses in
different ways. Seems clear now. Very similar to the issue you have if
you try to allocate with a memory allocator and deallocate with another
in different parts of the application.

>The only thing we can do for libstdc++ is to put something in the 
>config files that claims that atomic operations are *always*
>available for all members of the architecture family.  If so, we
>may inline them.  Otherwise, we should force the routines to be
>out-of-line in the library.  This provides the stable ABI that we
>require.
>
I think I get this too. This "quid"  in the config files basically is
info that we already have easily available: powerpc -> ok; alpha -> ok;
i?86 -> not ok; Sparc -> not ok, and so on (*) ... We only need to use
it in the configury of the library and either call the builtins or not
depending on the architecture family. We have to add to the library
out-of-line versions of the builtins... (in order to do that, we may end
up restoring the old inline assembly implementations of CAS, for example)

>  We may then use optimization flags to either implement
>the operation via atomic operations, or a mutex.
>  
>
If I understand correctly, this is what we are already doing in the
*.so, for i386 vs i486+. I would not call that "optimization flag",
however. Can you clarify?

Therefore, all in all, if I understand correctly, we:
1- Don't need new preprocessor builtins.
2- Don't need new libgcc code.
3- Do need out-of-line library versions of the various builtins for the
architecture families that don't implement uniformly the builtins (a lot
of work!).
4- Do need a bit of additional configury (bit of work).

Paolo.

(*) I think there is an annoying special case which is multilib x86_64:
in its 32-bit version belongs to the i?86 family and, as far as I can
see, we cannot inline the builtins for x86_64 tout court, or?!?