This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FW: [PATCH 2/2] ARM: Improve fenv implementation
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, 'Marcus Shawcroft' <marcus dot shawcroft at gmail dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 20 May 2014 09:49:32 +0100
- Subject: Re: FW: [PATCH 2/2] ARM: Improve fenv implementation
- Authentication-results: sourceware.org; auth=none
- References: <000801cf6ad1$64fd3a60$2ef7af20$ at com> <Pine dot LNX dot 4 dot 64 dot 1405181411410 dot 4608 at digraph dot polyomino dot org dot uk> <000001cf7384$89ae42d0$9d0ac870$ at com> <Pine dot LNX dot 4 dot 64 dot 1405191715550 dot 25418 at digraph dot polyomino dot org dot uk>
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.