This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Define HAS_CPUID/HAS_I586/HAS_I686 from -march=
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 18 Aug 2015 16:16:28 +0000
- Subject: Re: [PATCH] Define HAS_CPUID/HAS_I586/HAS_I686 from -march=
- Authentication-results: sourceware.org; auth=none
- References: <20150817231005 dot GA24205 at intel dot com> <20150818143258 dot GM1584 at vapier> <CAMe9rOov73oYeEtXF3OjK62xmRcm60ptU_LRo99=40OrUwhrWw at mail dot gmail dot com> <20150818160232 dot GN1584 at vapier> <CAMe9rOq52Vu1M7Z1kLA6qJBoHFSN9Vu9fmF7SHZTXjOXv+6reA at mail dot gmail dot com>
On Tue, 18 Aug 2015, H.J. Lu wrote:
> My change is based on sysdeps/x86/bits/string.h and
> sysdeps/x86/bits/byteswap.h. None of them check
> __i586__ nor __i686__.
Maybe
(a) there should be a new (installed) bits/ header for x86, say
bits/x86-arch.h, that defines __x86_arch to 4, 5 or 6 depending on such
macros, so the logic doesn't need duplicating;
(b) the header should test for the probably much smaller number of 486 /
586 processors supported by GCC, with the default being i686, to avoid
keeping needing updating it for future processors;
(c) GCC should add such a predefined macro, with bits/x86-arch.h only
defining it itself if not already defined, as further future-proofing
against anyone adding new support for an i486-class or i586-class
processor with new predefined macros?
(Cf. sysdeps/arm/memcpy.S working based on a list of ARM architectures
without preload support, instead of a list with it; and the __ARM_ARCH
macro from ACLE in newer versions of GCC.)
--
Joseph S. Myers
joseph@codesourcery.com