This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] [ARM] ] Add support for fenv_private on ARM
- From: "Wilco" <wdijkstr at arm dot com>
- To: "'Joseph Myers'" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 6 Mar 2014 19:31:57 -0000
- Subject: RE: [PATCH] [ARM] ] Add support for fenv_private on ARM
- Authentication-results: sourceware.org; auth=none
- References: <000b01cf3949$7e3a0080$7aae0180$ at com> <Pine dot LNX dot 4 dot 64 dot 1403061550110 dot 18293 at digraph dot polyomino dot org dot uk>
On Thu, 6 Mar 2014, Joseph Myers wrote:
> ARM_HAVE_VFP isn't suitable for use in #if; see the
> sysdeps/unix/sysv/linux/arm/arm-features.h definition. You need either a
> new macro meaning "VFP is known at compile time to be available", or to
> move to checks with "if" inside the functions.
Good point - it appears __SOFTFP__ is what I wanted:
diff --git a/sysdeps/arm/fenv_private.h b/sysdeps/arm/fenv_private.h
index 6c65cfa..0b73816 100644
--- a/sysdeps/arm/fenv_private.h
+++ b/sysdeps/arm/fenv_private.h
@@ -23,7 +23,7 @@
#include <fpu_control.h>
#include <arm-features.h>
-#if ARM_HAVE_VFP
+#ifndef __SOFTFP__
static __always_inline void
libc_feholdexcept_vfp (fenv_t *envp)
> (The case of a soft-float build, VFP hardware available at runtime - the
> one addressed by "if" conditionals - has other problems with exceptions
> and rounding modes, that I think would best be addressed by use of IFUNCs
> in libgcc for the relevant RTABI functions; see bug 10064. Anyway, the
> present patch is purely an optimization, so there's certainly no need for
> it to cover all cases as long as it doesn't break them.)
I think the best option is to not change the behaviour of fenv when you
use softfp but run on a CPU that supports VFP - especially since softfp
doesn't support rounding modes or exceptions.
I'm working on a patch to improve fenv with the same optimizations and
clean up the code, so can fix all the if (ARM_HAVE_VFP) to use __SOFTFP__.
On a related issue, the fenv testing code doesn't check the return code
of the fenv functions, which causes failures. It also assumes that fenv
functions set errno when this is not part of the C99 spec. Is that on
purpose or a bug?
Wilco