This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] libm-test: switching the error handling behavior
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, aj at suse dot com, joseph at codesourcery dot com, Siddhesh Poyarekar <siddhesh at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Date: Thu, 04 Apr 2013 10:21:32 -0400
- Subject: Re: [PATCH] libm-test: switching the error handling behavior
- References: <871uaqzheb dot fsf at schwinge dot name>
On 04/04/2013 07:04 AM, Thomas Schwinge wrote:
> How to address the part of the comment suggesting that we might have to
> change the hardware FPU exception settings? A few architectures define
> _FPU_IEEE, and have fesetenv use that for FE_NOMASK_ENV, but using the
> latter is not the right thing to do as that would cause any floating
> point exception to raise SIGFPE. On the other hand, it seems to me that
> linking with -lieee (math/Makefile: ÂThe -lieee module sets the
> _LIB_VERSION_ switch to IEEE mode for error handling in the -lm
> functions.Â) appears to be equivalent to just setting _LIB_VERSION to
> _IEEE_ (as I'm doing in my patch), and also doesn't seem to cause any
> special hardware FPU exception settings?
Yes, _FPU_IEEE will cause exceptions to be raised and then you'd
need exception handlers.
Yes, using -lieee today only changes the global variable and does
nothing else, which is probably not sufficient on some hardware like
ARM which has a run-fast VFP mode that is non-IEEE.
You want -lieee to set _LIB_VERSION to IEEE mode, do whatever is
required in hardware to enable IEEE mode, but not enable all of the
exceptions, since that would go against the default starting
mode of FE_DFL_ENV?
or
You want a function that sets the libm mode e.g. set_libm_mode_np("IEEE");?
Both seem like a reasonable request.
Given sufficient new documentation in the manual to describe
in more detail the current solution I'd be happy with both.
Is this a similar to the case of default POSIX thread stack size?
What we're doing there is creating a library that is loaded
first and runs a constructor, calling whatever internal or
non-portable API functions are required to set the default.
This has the benefit of avoiding the startup code for all other
applications that just run with the default.
Could you do the same thing here?
Cheers,
Carlos.
Note:
- At some point we will have to redraw the design for all of these
defaults into something more generic and designed for testing.