Piotr Wyderski wrote:
I am working on a portable low-level library of atomic operations,
Like the existing libatomic-ops package?
Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that
Jakub was probably describing how it works on linux. On Solaris, Sun
sets the standard, and we have to follow Sun's lead here. It appears
that the Sun compiler only defines __sparc_v9 for 64-bit compiles, so
gcc must do so also. This is done in the gcc/config/sparc/sol2-bi.h
file which is only used for solaris2.7 and up. If this assumption about
the Sun compiler is wrong, then this is a gcc bug. Otherwise, no.
-mcpu=i386 => __i386 = 300
I think this could get confusing very quickly. What values do we use
for AMD parts? What values do we use for PentiumD parts which have
3-digit part numbers that conflict with this scheme?
This info may also not be accurate enough to be useful in the end.
Different pentium4 cores have different sets of features. So just
knowing that something is a P4 isn't good enough to know what
instructions exist. You have to have run time checks to read system
registers that contain info about what hardware features are present.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
