This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
I am going nuts over this issue, maybe someone can help me see the light here: In the info page for egcs it is documented: --- quote --- These `-m' options are defined for the i386 family of computers: `-mcpu=CPU TYPE' Assume the defaults for the machine type CPU TYPE when scheduling instructions. The choices for CPU TYPE are: `i386', `i486', `i586' (`pentium'), `pentium', `i686' (`pentiumpro') and `pentiumpro'. While picking a specific CPU TYPE will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the `-march=CPU TYPE' option being used. `-march=CPU TYPE' Generate instructions for the machine type CPU TYPE. The choices for CPU TYPE are: `i386', `i486', `pentium', and `pentiumpro'. Specifying `-march=CPU TYPE' implies `-mcpu=CPU TYPE'. `-m386' `-m486' `-mpentium' `-mpentiumpro' Synonyms for -mcpu=i386, -mcpu=i486, -mcpu=pentium, and -mcpu=pentiumpro respectively. --- endquote --- So after reading this thing one clearly gets the impression the saying -mcpu=i486 will affect the scheduler only, while egcs will still generate code that will run on i386, and -march=i486 will actually enable i486-specific instructions. Well, the cpp does not concur to this idea and because of this the glibc headers that are testing for __i486__ (like the ones that define bswap32 and bswap16) are getting confused. A common sense rule says that using -mcpu=i486 should *not* define __i486__, because we don't want to use i486 specific code, we are only interested in the scheduler modifications. but this is not true: shefu (gafton):~>gcc -dM -E -mcpu=i486 - < /dev/null #define __linux__ 1 #define linux 1 #define __i386__ 1 #define __i386 1 #define __i486 1 #define __GNUC_MINOR__ 91 #define __i486__ 1 #define i386 1 #define i486 1 #define __unix 1 #define __unix__ 1 #define __GNUC__ 2 #define __linux 1 #define __ELF__ 1 #define unix 1 The same rule, after reading the info page, says that __i486__ should get defined if we use -march=i486. But again, it does not get defined: shefu (gafton):~>gcc -dM -E -march=i486 - < /dev/null #define __linux__ 1 #define linux 1 #define __i386__ 1 #define __i386 1 #define __GNUC_MINOR__ 91 #define i386 1 #define __unix 1 #define __unix__ 1 #define __GNUC__ 2 #define __linux 1 #define __ELF__ 1 #define unix 1 As a result, ./sysdeps/i386/bits/byteswap.h is testing for __i486__ and because the cpp from egcs defines it when using -m486 it will pick the variant that is using bswap calls, which are not available on i386. So the claim that the code should continue to run i386 without problems is not true. Bottom line: people used to belive that compiling programs against glibc headers using -mcpu=i486 will generate code that will run on i386 or higher, but it will run fastest on pentium because of the optimized scheduler. Now this proves to be exactly the opposite: -mcpu=i486 will break things badly. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |