This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: [PATCH 2/2] ARM: Improve fenv implementation


On 19/05/14 18:26, Joseph S. Myers wrote:
> On Mon, 19 May 2014, Wilco wrote:
> 
>>> Joseph Myers wrote: 
>>> This breaks the build when VFP isn't enabled at compile-time, because then
>>> the libc_* functions aren't defined.  You need to have the <fenv.h>
>>> functions conditionally call libc_* functions that always use VFP (and are
>>> always defined), while those VFP-using functions are only conditionally
>>> used within the rest of libm.  I.e., I think the __SOFTFP__ conditionals
>>> in fenv_private.h should only control the definitions of libc_* to use
>>> libc_*_vfp, not the definitions of the libc_*_vfp inlines.
>>
>> You're right, it wouldn't build properly. I'll move the #ifndef __SOFTFP__
>> to go just before the defines and add the reverted patch to my outstanding 
>> patch set.
>>
>> Any chance we can obsolete softfp only builds any time soon? I can't
>> remember when the last non-VFP ARM was made, but it must have been at
>> least a decade ago... Are those NetWinder boards still working/in use?
> 
> That would be very premature.  You still get people building glibc for v4 
> (not v4T) although only v4T and above are really expected to work properly 
> for EABI.  VFP is still optional in v7 (without the "only for 
> implementations targeting specialised markets" caveat of v8); my 
> impression was that there are Cortex-A9 processors without VFP, for 
> example.
> 

I'm aware of Cortex-A9s without Neon, and thus implementing VFPv3-D16,
but I don't recall ever seeing one without the FP unit.

[Someone will no doubt show me to be wrong though :-) ]

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]