Paolo Carlini:
Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user A,
who just types g++ foo.cpp and expects to get a program that works well
on a typical machine, and user B, who types g++ -march=i386 foo.cpp, with
the explicit intent to run the result on a 386.
Maybe "no way" is a tad too strong: now we have
|__GCC_HAVE_SYNC_COMPARE_AND_SWAP_? and more could be added...
I may be missing something, but doesn't testing __i486__ give me the same
information as __HAVE_CAS_x in this case?
The problem is not that the library cannot distinguish between -m386
and -m486; the problem is that it cannot distinguish between explicit -m386
and implicit -m386.
This is an issue because many users target i386 by accident and not by
design simply because it is the default in many g++ installations.
In practice, when one does:
g++ foo.cpp
g++ -m586 bar.cpp
g++ foo.o bar.o
it is reasonable to expect the end result to work on a 586 or better.
But if a library header uses spinlocks on 386 and inlined __sync on 586, the
code will fail in subtle ways, because the manipulation of some shared
variables may no longer be atomic.
The only solution today for the above situation is to ignore the lack of
__i486__ and consistently use cmpxchg. This of course is not good for people
who explicitly target i386.
If g++ defaults to i486, the libraries can use the lack of __i486__ as a
definite sign of the user explicitly targeting i386, in which case they can
safely refrain from using cmpxchg/xadd without fear of breaking the above
example.
