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

[Marcus Shawcroft <marcus dot shawcroft at gmail dot com>]

On 6 March 2014 22:32, Joseph S. Myers <joseph@codesourcery.com> wrote:

> 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).

IIRC the relevant part of test-fenv.c in the context of this thread is:

  errno = 0;
  fesetenv (FE_NOMASK_ENV);
  status = errno;
  fesetenv (&saved);
  if (status == ENOSYS)

There is one target in the glibc tree that appears to make use of
errno in this manner, sysdeps/powerpc/fpu/fesetenv.c has a path that
calls __fe_nomask_env_priv() setting ENOSYS, curiously this fesetenv()
implementation always returns 0 even when setting errno, which seems
rather odd to me, I wonder if  this is by design or simply a hang over
from the days before fesetenv() gained a return value?

Given Joseph's comments above and the existing use of errno in this
context it doesn;t seem unreasonable to me that both arm and aarch64
might also set ENOSYS on platforms that do not support trapping
exceptions.

/Marcus