[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131118195931.GK24286@brightrain.aerifal.cx>
Date: Mon, 18 Nov 2013 14:59:31 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: math_errhandling definition
On Mon, Nov 18, 2013 at 12:13:25AM +0100, Szabolcs Nagy wrote:
> * Bobby Bingham <koorogi@...rogi.info> [2013-11-17 15:54:54 -0600]:
> > I think the definition of math_errhandling is wrong on a couple
> > architectures. C99 (7.12) says:
> >
> > If the expression math_errhandling & MATH_ERREXCEPT can be nonzero,
> > the implementation shall define the macros FE_DIVBYZERO, FE_INVALID,
> > and FE_OVERFLOW in <fenv.h>.
> >
> > math.h always defines math_errhandling as 2 (MATH_ERREXCEPT), but
> > whether those FE_* macros are defined or not is architecture-dependent.
> > In particular, ARM only defines them if __ARM_PCS_VFP is defined, and
> > microblaze does not define them.
> >
> > It looks like if the architecture doesn't support floating point
> > exceptions, math_errhandling must be MATH_ERRNO. This in turn requires
> > that the various math functions set errno appropriately, which it
> > doesn't look like musl's do.
>
> yes, but..
>
> musl aims to support annex f
>
> annex f requires math_errhandling & MATH_ERREXCEPT to be true
> ie math errors are reported as floating-point exceptions
> according to ieee 754 semantics
>
> annex f also requires all five ieee status flags to be defined
> FE_OVERFLOW, FE_UNDERFLOW, FE_DIVBYZERO, FE_INVALID, FE_INEXACT
>
> (c99 requires that unsupported flags are not defined and has
> weaker requirements without annex f as you quoted)
>
> unfortunately c99 made it (nearly) impossible to implement
> floating-point with ieee exception semantics in software and
> indeed gcc does not provide exceptions for fpu-less archs
> (unless the underlying arch has hw registers for it)
>
> this is fixed in c11 which changed signal handler semantics wrt
> the floating-point environment and introduced thread storage
> duration (however libgcc does not implement fp status flags with
> thread storage duration just yet)
>
> musl can only support annex f if the underlying hardware
> (or on fpu-less archs the compiler or kernel fp emulation)
> support ieee754
>
> in short this should be reported against libgcc
>
> in theory we could support MATH_ERRNO on such platforms, but
> it would be a significant effort and still would not give useful
> fp semantics other than slightly stricter c99 conformance
Yes, nsz summed this up very nicely. Bobby, is there a practical issue
you're hitting with the lack of math_errhandling on these archs, or
are you just concerned with conformance from a theoretical standpoint?
I ask mainly because this will help us consider how to deal with the
issue in the future and what to prioritize. My general feeling right
now is that ARM users should prefer the "armhf" ABI whenever possible,
and that using microblaze for floating point computation is just a bad
idea to begin with. But we'll have to consider other archs as they are
added (if others lack fp exceptions ABIs) and whether proper
soft-float with exceptions is on the way...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
