This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 16 Mar 2010 12:53:34 -0700
- Subject: Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
- References: <4B9FDCC1.2080201@oracle.com>
On Tue, Mar 16, 2010 at 12:32 PM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> Hi,
>
> I'm rather surprised that now, in the "sane default world", only __i386 is
> defined, whereas __i686 is not on x86_64 -m32, I need -march=i686 on the
> command line (together with -m32).
>
> I noticed that while analyzing libstdc++/43394, where I was surprised that
> some preprocessor lines, legacy code actually, in the library code for
> parallel mode do not "notice" that we have now a better default:
>
> #elif defined(__GNUC__) && defined(__i386) &&?????????????????? \
> ? (defined(__i686) || defined(__pentium4) || defined(__athlon))
> ??? return __sync_fetch_and_add(__ptr, __addend);
>
> ... indeed, such lines want __i686 in order to safely enable the builtin and
> still find it undefined.
>
> If - as it's probably the case - I'm a bit confused about the meaning of
> those __i?86 macros, what people suggest instead? I suspect my
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* could be put to good use, still I'm still
> curious about the exact semantics of the __i?86 macros...
>
> Thanks in advance,
> Paolo.
The question is what processor macros should "-march=x86-64" define. There
is
{"x86-64", PROCESSOR_K8, CPU_K8,
PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},
For -march=x86-64, __k8 is defined. However, real K8 supports:
{"k8", PROCESSOR_K8, CPU_K8,
PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
| PTA_SSE2 | PTA_NO_SAHF},
It isn't an issue in i386.c since PROCESSOR_K8 isn't used to check
ISAs. But using __k8 to check ISAs is a problem.
--
H.J.