------- Comment #12 from pcarlini at suse dot de 2006-08-25 08:08 ------- (In reply to comment #11) > Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing > for __sync_fetch_and_add support) that the compiler should provide it as a > preprocessor symbol.
Yes, and a patch for that would be definitely welcome, I was going to work on it, per: http://gcc.gnu.org/ml/libstdc++/2006-07/msg00103.html http://gcc.gnu.org/ml/libstdc++/2006-07/msg00106.html but, as I said, you are very welcome. That symbol would be immediately useful for header code not calling into the library (-> no compatibility problems, e.g., tr1::shared_ptr would be immediately changed to use it). However, for the atomicity *headers* themselves, we don't want to exploit fine grained info about the sub-target on x86, Sparc, for example, because we want user code independent from the atomicity model, without going for mutexes everywhere (old story about distros: don't want to prepare separate distros for i386 and i486): in such cases the atomicity routines must remain out-of-line in the compiled library. However, that reasoning means that, as I suggested already, in those cases you could exploit anyway the dynamical preprocessor builtin when building the routines in the out-of-line library (that would enable exploiting the builtins on i486+ for example). Much more sophisticated approaches, optimal in every case, are possible only by way of multilibs, AFAIK (also discussed a lot in the past). Agreed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
