This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH roland/arm-hwcap-vfp] don't use HWCAP_ARM_* in OS-independent code
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-ports at sourceware dot org>
- Date: Thu, 9 Aug 2012 11:16:27 +0000
- Subject: Re: [PATCH roland/arm-hwcap-vfp] don't use HWCAP_ARM_* in OS-independent code
- References: <20120808235921.AA4292C075@topped-with-meat.com>
On Wed, 8 Aug 2012, Roland McGrath wrote:
> This change is not quite just a a no-op abstraction of the existing
> logic. I also made the generic sysdeps/arm/ code define ARM_HAVE_VFP to
> a constant when __VFP_FP__ is predefined. My rationale is that if the
> compiler building libc is allowed to generate VFP instructions, then
> we're already implicitly presuming the hardware exists at runtime and so
> we might as well skip the explicit runtime checks in libc too.
__VFP_FP__ doesn't mean "generating VFP instructions", it means
"floating-point types have VFP layout" (i.e. normal IEEE floating-point
with the same byte ordering / endianness as integer types, as opposed to
FPA format), which is always true for EABI. The relevant test for
"generating VFP instructions" is defined __VFP_FP__ && !defined __SOFTFP__
(which can be simplified to just !defined __SOFTFP__ given that EABI is
assumed).
--
Joseph S. Myers
joseph@codesourcery.com