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
On 8/9/2012 1:10 PM, Roland McGrath wrote:
>> __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).
>
> Thanks for the explanation. I've changed the conditionals. On further
> reflection I also decided that using ldsodefs.h was just too ugly and I've
> added an arm-features.h instead.
>
> How does this look now?
>
>
> Thanks,
> Roland
>
>
> ports/ChangeLog.arm
> 2012-08-09 Roland McGrath <roland@hack.frob.com>
>
> * sysdeps/arm/arm-features.h: New file.
> * sysdeps/unix/sysv/linux/arm/arm-features.h: New file.
If we are going to make a new internal header for this kind of thing
can you please add a "Internal Headers" section in the "Internals Documentation"
part of the wiki and mention briefly "*-features.h" and when and why you might
use it?
http://sourceware.org/glibc/wiki/HomePage#InternalsDocumentation
Alternatively add this to manual/maint.texi please :-)
Cheers,
Carlos.