On 11/22/05, Jim Wilson <[EMAIL PROTECTED]> wrote: > 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.
Like f.i. as I proposed in http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html maybe you could comment on that approach. Sofar the feedback was negative, so I didn't yet work further on it. Richard. > -- > Jim Wilson, GNU Tools Support, http://www.specifix.com >
