Re: [zahn@berlin.snafu.de] libc/1149: #ifdef __i686__ problematic to generate 686-dependent code

[Philip Blundell <Philip.Blundell@pobox.com>]

>	I find the use of constructs of the form
>        #ifdef __i686__
>        to generate 686-dependent code problematic. This is done in
>        glibc-2.1.1/sysdeps/i386/i486/bits/string.h:1261
>        and also in /usr/include/bits/string.h.
>        If in the above places the symbol __i686__ is defined then
>        the generated code will only run on processors with
>        cmove instruction, i.e. i686.
>        Now the __i686__ symbol cannot distinguish between
>        -mpentiumpro and -march=pentiumpro. I had the case that
>        -mpentiumpro was the default configuration of egcs on a machine

I tend to feel that egcs shouldn't be defining __686__ in the -mpentiumpro 
case.  IMHO, the ideal would be to have egcs define __686__ iff 
-march=pentiumpro was given, and to either have glibc inspect the 
configuration name for optimization information, or (preferably) add another 
set of predefines to the compiler.  This seems to give the least surprising 
results; compiling on a 686 with no special flags would yield code tuned for 
686 but capable of running on any cpu (which is probably what's wanted).

If we follow the course that the original reporter suggested and base the 
choice of what opcodes to use in glibc on the configuration name, we will end 
up with the default behaviour on a 686 system being to generate 686-only code 
regardless of compiler options, which is surely undesirable.

p.