[RFC] libstdc++ atomicity, x86 agnostic version

[Benjamin Kosnik]

Currently, the atomicity.h functions are used by:

%grep "atomicity.h" include/*/*.h | grep include
include/bits/basic_string.h:#include <bits/atomicity.h>
include/bits/ios_base.h:#include <bits/atomicity.h>
include/bits/locale_classes.h:#include <bits/atomicity.h>
include/ext/mt_allocator.h:#include <bits/atomicity.h>
include/ext/pool_allocator.h:#include <bits/atomicity.h>

This includes reference counting in std::string, std::ios_base
callbacks, std::locale::facet and std::locale::_Impl, and in various
allocator classes.

Although considered useful, this implementation has one drawback: on one
popular platform, (x86/linux), switching between atomicity files for
i386 and i486 and above is not compatible. Thus, when using i486 and
above libstdc++, all C++ applications (and thus C++ packages in an os
distribution) have to be compiled for both i386 and i486+. I believe
this has been an issue for Red Hat, Debian, and perhaps BSD.

One way around this would be to make these atomic functions gcc
builtins. These would be different semantics than other gcc builtins,
however, because there could be no fall back to a support library in the
case of failure to use the builtin.

Another would be to not define these functions in headers, and instead
put them into libstdc++.so, version them, and then export them. See the
attached patch, which was discussed in last week's tools conference
call. With this, linux distributions for i386 could use 

libstdc++-3.3.2-1.i386.rpm

And non-i386 x86/linux distros could use

libstdc++-3.3.2-1.i686.rpm

Then, regardless of the processor, all other C++ applications could be
compiled i386 and be expected to work reliably on both i386 and i686.
This is exactly similar to what the "C" library does.

I expect some comments about the fact that these atomic functions will
no longer be inlined, impacting performance. Therefore, I attach the a
performance testrun with the patch, which shows a minimal impact.

I'll wait 24 hrs for feedback. I'd like to check this into mainline and gcc-3_4-branch.

best,
benjamin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20040225-1.bz2
Type: application/x-bzip2
Size: 11158 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20040225/51936f25/attachment.bz2>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20040224-libstdc++-performance-atomic.sum
Type: application/octet-stream
Size: 22329 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20040225/51936f25/attachment.obj>