RE: [PATCH] [ARM] ] Add support for fenv_private on ARM

["Joseph S. Myers" <joseph at codesourcery dot com>]

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