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]

egcs 2.91.66 ix86 problems...



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]