Re: cxx-mem-model merge [6 of 9] - libstdc++-v3

[Benjamin Kosnik <bkoz@redhat.com>]

> > I just realized I may be feeding you an inconsistent
> > configuration, see the atomicity stuff in
> > libstdc++-v3/config/cpu/cris.  Is that just obsolete and unused
> > now or what do I need to add for that to work?
> >
> 
> You don't need to do anything there. I think that atomicity stuff
> will soon be obsolete, but bkoz will have to answer that question.
> It looks to me like that was some gnu atomic extentions which predate 
> atomic support in the standard.  In theory, that would all be able to
> go away or be integrated into the gcc machine description with the
> modern patterns, if its not already there.

That is very obsolete and should be removed as it's now just
causing confusion. That was pre-builtin days, let's call this
atomics-try-1. So, all:

config/cpu/*/atomicity.h
./i486/atomicity.h
./i386/atomicity.h
./sparc/atomicity.h
./sh/atomicity.h
./m68k/atomicity.h
./cris/atomicity.h
./hppa/atomicity.h
./generic/atomicity_mutex/atomicity.h
./generic/atomicity_builtins/atomicity.h

ATOMICITY_SRCDIR
ATOMIC_WORD_SRCDIR
ATOMIC_FLAGS

Should go. I'll look in to peeling off this cruft sharpish.
 
> bkoz: As relates to the existing problem, how is the legacy support 
> invoked in compatibility-atomic-c++0x.cc?  That has the old style 
> implementation of atomic_flag with a lock, which would allow this
> target to compile...  which is another option perhaps.  or is that
> purely for pervious releases somehow?

compatibility-atomic-c++0x.cc is the support for previous builtins
attempt, let's call this atomics-try-2. We need to keep these symbols
exported and doing the same thing done in previous releases. (Or else
abi-check will fail.)

If this system used to use a lock to work, then that is what it should
still do. The behavior shouldn't change.

 -benjamin