This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libm-test: switching the error handling behavior


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]