math_errhandling definition

math_errhandling definition

[Bobby Bingham]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

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.

--
Bobby Bingham

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: math_errhandling definition

[Szabolcs Nagy]

* Bobby Bingham <koorogi@koorogi.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

Re: math_errhandling definition

[Rich Felker]

On Mon, Nov 18, 2013 at 12:13:25AM +0100, Szabolcs Nagy wrote:
> * Bobby Bingham <koorogi@koorogi.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

Re: math_errhandling definition

[Bobby Bingham]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Mon, Nov 18, 2013 at 02:59:31PM -0500, Rich Felker wrote:
> [...]
> 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?

No practical issue. I just stumbled across this part of the spec while
trying to determine if some of gcc's output on SH4 was conforming or
not.

Is the differences in the level of conformance on the different
architectures documented anywhere?  The "Introduction to musl" page on
the website states that "minimal machine-specific code means less change
of breakage on minority architectures and better success with 'write
once run everywhere' C development".  It would probably be worthwhile to
document known exceptions to that when they exist.

--
Bobby Bingham

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: math_errhandling definition

[Rich Felker]

On Tue, Nov 19, 2013 at 11:27:15PM -0600, Bobby Bingham wrote:
> On Mon, Nov 18, 2013 at 02:59:31PM -0500, Rich Felker wrote:
> > [...]
> > 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?
> 
> No practical issue. I just stumbled across this part of the spec while
> trying to determine if some of gcc's output on SH4 was conforming or
> not.
> 
> Is the differences in the level of conformance on the different
> architectures documented anywhere?  The "Introduction to musl" page on
> the website states that "minimal machine-specific code means less change
> of breakage on minority architectures and better success with 'write
> once run everywhere' C development".  It would probably be worthwhile to
> document known exceptions to that when they exist.

Yes, I agree. That should go in the manual somewhere -- in fact I
think it merits a chapter/section on what aspects (at least in the
scope of what's visible to a conforming program) of the library vary
between supported archs.

Rich