[PATCH] [ARM] ] Add support for fenv_private on ARM
Joseph S. Myers
joseph@codesourcery.com
Thu Mar 6 22:32:00 GMT 2014
On Thu, 6 Mar 2014, Wilco wrote:
> > (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.
The best option for the present patch. I'd like such a configuration to
work properly (i.e. when the fenv functions succeed they also do affect
arithmetic operations), but that needs the IFUNCs.
(Having VFP implementations of the RTABI functions in libgcc conditioned
at compile time on __SOFTFP__ is a good idea simply for efficiency, if a
soft-float object file is linked with libraries built for VFP - as well as
making libgcc smaller when built for VFP, as the VFP implementations
should be smaller than the soft-float ones (cf. the recent change in
libgcc on MIPS to use minimal implementations of various libgcc functions
for hard float, rather than the previous soft-float versions also used in
hard-float libraries). IFUNCs for libgcc built for soft float is a step
beyond that, which would make libgcc consistent with glibc.)
> 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__.
But that's not correct in the cases where a runtime check is used (and in
general, if () conditions are better than #if because they mean both cases
still get checked for syntax on every compilation).
I suppose logically there are two meaningful soft-float configurations,
one with runtime checks for VFP in both libgcc and glibc, and one with no
such checks in either place and the present VFP support in glibc disabled.
The former makes sense for general-purpose distributions supporting a wide
range of hardware (e.g. Debian armel), by producing binaries that adapt
automatically to the functionality of the hardware they run on; the latter
if the binaries are only intended for specific soft-float hardware.
> 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?
That should just be math/test-fenv. There's a trade-off between:
* detecting a failure as meaning the feature is unsupported and so making
the test quietly PASS, when actually the failure is not expected on the
given platform and so it should have FAILed, and
* treating any failure as meaning the test fails, when actually it might
be expected on a given platform.
I suppose I'd be inclined to say that test-fenv should use macros from
math-tests.h to indicate which functions are expected to work on a given
platform and which are expected to fail (on ARM you'd need some
initialization step to determine whether traps for exceptions are
supported). So unless a platform says certain failures are OK, they would
make the test as a whole fail.
As for errno setting, generally ISO C says little about errno but the norm
for POSIX and glibc functions is to set errno on error unless there is
some other defined way to indicate what error occurred (e.g. functions
defined to return an error number).
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list