This is to track this issue: http://gcc.gnu.org/ml/gcc/2005-11/msg00285.html In a nutshell, we need an easy way to exploit the new atomic builtins in the library, irrespective of the actual target.
Maybe the easy way to fix this is just have the distro change their policy of compiling with i386 to compile always with i686.
(In reply to comment #1) > Maybe the easy way to fix this is just have the distro change their policy of > compiling with i386 to compile always with i686. Indeed, that's one point. However, there isn't only i386 to cause problems, also old Sparc. And targets which *may* have builtins but are simply not implemented, for one reason or another. And situations at the border, e.g., hppa. Really, we want a *uniform* way to call the builtins from the library.
(In reply to comment #2) Let first point out i486 is more than 15 years old. Second why do you really need an uniform way? This seems like a way to make everything in the compiler. Maybe next you will be asking for the template string to be part of the compiler and not the library (maybe I am going over board here)? Oh, for libobjc I need a way to describe the alignment and sizes of a struct can that be built into the compiler too please (Really I don't think it should).
(In reply to comment #3) > Let first point out i486 is more than 15 years old. Sure, but it's not up to me and you to decide what is on the market, in embedded form or otherwise. And it's not only about i386, again, please read my previous message. .................................................(maybe I am going over > board here)? Definitely.
http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html In short, you'll never get a completely unified way to implement these routines.
(In reply to comment #5) > http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html > > In short, you'll never get a completely unified way to implement these > routines. Disagree, see: http://gcc.gnu.org/ml/gcc/2005-11/msg00332.html
I stand by my statement. This cannot go in libgcc.
Paolo, the only viable way to get these inlined looks like a libstdc++ configure-time choice to say --disable-i386-support or sth like that. You then build libstdc++ against the atomic builtin primitives and at application build-time either try falling back with preprocessor stuff rth suggested, or don't do it and fail either at compile-time or later (maybe) at runtime with some SIGILL or whatever you'll get. Supporting different architectures and inlining at the same time is not possible (well, apart from fixup by binary-patching at program startup, like the kernel does (or did?), of course ;))
(In reply to comment #8) > Paolo, the only viable way to get these inlined looks like a libstdc++ > configure-time choice to say --disable-i386-support or sth like that. You then > build libstdc++ against the atomic builtin primitives and at application > build-time either try falling back with preprocessor stuff rth suggested, or > don't do it and fail either at compile-time or later (maybe) at runtime with > some SIGILL or whatever you'll get. I would certainly be in favor of something like that, it's a real pity that the vetust i386 blocks us in using the new builtins and inlining the atomic operations. I'm still convinced that something more general would be better, but I can (rather easily) implement Rth idea too, otherwise. Of course it's still open the task of preparing inline assembly implementing the various atomic operations for arches which don't have (for one reason or another) the builtins... > Supporting different architectures and inlining at the same time is not > possible (well, apart from fixup by binary-patching at program startup, like > the kernel does (or did?), of course ;)) Please provide a detailed scenario, again.
Ok, apparently short-term at least, "smart" solutions using libgcc and dynamic linking will not be implemented (one blocker are systems using a static libgcc.a). Therefore this one becomes a pure libstdc++-v3 PR. Then what we can improve is rather limited: we can inline the atomics on architecture families that uniformly implement the builtins (e.g., powerpc -> ok, i?86 -> not ok). The atomics will also remain in the library, however, for ABI stability reasons.
Changing the declarations in include/bits/atomicity.h to inline definitions forwarding to the builtins and including <bits/atomic_word.h> instead of <bits/atomicity.h> in config/cpu/*/atomicity.h for the supported arch families would be most of it, probably.
Any news on this bug?
No news about this one. Frankly, since x86-* would not benefit in any way, I consider the work low priority.
(In reply to comment #13) > No news about this one. Frankly, since x86-* would not benefit in any way, I > consider the work low priority. What about x86_64 or even PowerPC64 both of which are becoming more popular than x86. In fact in a few years PPC64 might even supass x86 usage (but only because of the PS3).
(In reply to comment #14) > (In reply to comment #13) > > No news about this one. Frankly, since x86-* would not benefit in any way, I > > consider the work low priority. > > What about x86_64 Of course by x86-* I meant to include x86_64.
Subject: Bug 24692 Author: paolo Date: Mon May 29 20:00:29 2006 New Revision: 114215 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114215 Log: 2006-05-29 Paolo Carlini <pcarlini@suse.de> PR libstdc++/24692 * include/bits/atomicity.h (__exchange_and_add_multi, __atomic_add_multi): New, depending on _GLIBCXX_ATOMIC_BUILTINS, inline the atomic builtins. (__exchange_and_add_dispatch, __atomic_add_dispatch): Adjust. * configure.ac: Define _GLIBCXX_ATOMIC_BUILTINS when the atomic builtins are available. * configure: Regenerate. * config.h.in: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/bits/atomicity.h
Fixed.