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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Wilco <wdijkstr at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 7 Mar 2014 17:08:16 +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> <000c01cf3972$bd2b72f0$378258d0$ at com> <Pine dot LNX dot 4 dot 64 dot 1403062208480 dot 23661 at digraph dot polyomino dot org dot uk> <CAFqB+Pz-vGKtBzZY+1riWRt1ro5V7oLHyGDdyjWsCEXCZiQwgw at mail dot gmail dot com>
On Fri, 7 Mar 2014, Marcus Shawcroft wrote:
> 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 the lack of other cases setting errno in <fenv.h> functions, it
might be better here simply to check the return value - and not to check
errno at all. But I think allowing failure should be conditional on
something from math-tests.h saying the architecture intends that this
feature might not be supported.
--
Joseph S. Myers
joseph@codesourcery.com