> > 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
