On Sat, 2 May 2009, Paolo Carlini wrote: > I don't think you are doing anything wrong, it's just that in libstdc++ we are > moving away from doing link tests. In my understanding, that would be nice > also for the other libraries but of course leads yo weaker tests. Now, in > order to make progress, I think we should first figure out if and to what > extent we have now a libgcc such that the atomic builtins can be assumed to > be unconditionally available to the user, thus either expanded inline or > provided on all the supported targets in libgcc. Besides that, we could maybe > add a configure time option to tell the library to just assume the > availability of the atomic builtins, thus not relying on weak compile-type > tests. We could also add safe special cases to the configury, like assuming > all the linux targets are now ok, one way or another.
Linux targets *don't* necessarily have the __sync_* functions. For example, they are not available on ColdFire (even with Maxim's TLS patch which I imagine will be updated and reposted in due course now we are in Stage 1), since atomic operations there use a kernel helper in a vDSO. It would be possible for libc to provide these functions, but that's not in the present specification or implementation. If anyone is still using ARM old-ABI, they aren't in libgcc there either. It is however safe on Linux targets to do link tests rather than just looking at the .s output of the compiler (looking at .s output being what gives misleading results when the functions are in libgcc or libc rather than built in). But there is one further complication. C++ shared libraries are linked with -shared-libgcc by default. The __sync_* functions on ARM and PA are in static libgcc only (and it looks like those on SH are always hidden, so effectively also static-only). So you can't actually link a C++ shared library that uses these functions. I consider this a compiler bug; even with -shared-libgcc I think the compiler needs to link with the static libgcc, after the shared one, so that undefined references to static-libgcc-only functions such as these can be resolved. > To end, just want to remind that this issue is essentially very old, just less > to the fore now thanks to the fact that x86_64 is so popular: eg, it woul be > so nice if people targeting i?86 could assume the builtins to be always > available. On i486 and later they are available. As for i686-pc-linux-gnu not defaulting to -march=i686 in the compiler (libstdc++ does select directories based on the target name as if it did mean -march not -mtune, however), perhaps someone could review HJ's patch <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html>? -- Joseph S. Myers jos...@codesourcery.com
