Implementing C99's roundf(), round(), and roundl()

[Bruce Evans]

On Wed, 21 Jan 2004, David Schultz wrote:

> On Tue, Jan 20, 2004, Bruce Evans wrote:
> > I think getting FE_INEXACT from rint() is the usual case (if the
> > implementation actually raises it), so we gain little or negative from
> ...
> If you have something in mind that will work, and you have the
> time to code it up, then by all means present or commit it.  You
> probably have a better idea than I do about the best way to deal
> with the exceptions and whatnot.  (Thanks again for taking the
> time to look at all of this, by the way.)

I probably won't get to this soon (enough).  I should give priority
to other things.

> When FENV_ACCESS is on, C99 requires compiler-optimized code to be
> affected by any operative modes in effect at runtime and set any
> exception flags at runtime as if no optimizations had been
> performed.  gcc is flat out broken in this regard, as I think
> you've pointed out in the past.  Even with FENV_ACCESS on (though
> likely ignored entirely), the code generated for 'd = 0.0 / 0.0' is:
>
>                 movl    $0, %eax
>                 movl    $2146959360, %edx
>                 movl    %eax, -8(%ebp)
>                 movl    %edx, -4(%ebp)

Unless you have a special version of gcc, it is just ignored:

    $ cat z.c
    #pragma FENV_ACCESS ON
    #pragma FENV_ACCESS is broken
    $ cc -c z.c
    $ cc -c -Wall z.c
    z.c:1: warning: ignoring #pragma FENV_ACCESS ON
    z.c:2: warning: ignoring #pragma FENV_ACCESS is

> Given that gcc is so broken with respect to exceptions, the fact
> that the math libraries don't raise the appropriate exceptions is
> not a big concern given that basic arithmetic operations often
> don't raise exceptions either.  When gcc is fixed, both of these
> problems will go away simultaneously.  Nevertheless, if we
> implement fenv.h now, we (a) are able to clean up libm sooner and
> (b) are a step ahead when gcc supports exceptions better.  It
> doesn't seem like we have much to lose by going ahead and
> implementing fenv.h, so at the very least we can use it in our own
> libraries.

I agree.

Bruce