[llvm-dev] fenv.h vs the optimizer

[Reid Kleckner via llvm-dev]

LLVM has never really supported fenv.h:
https://llvm.org/bugs/show_bug.cgi?id=8100

Even if we added support for the rounding modes, we don't support non-call
exceptions either:
https://llvm.org/bugs/show_bug.cgi?id=1269

I think there is interest in addressing the rounding mode stuff, but less
interest in modelling FP side effects. Medhi had some ideas around this.

On Thu, Aug 18, 2016 at 1:12 AM, Will via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> Howdy all,
>
> I've been playing around with programs that use the C11 fenv.h.
>
> It seems that, currently, the LLVM compiler does not regard to the
> exception-flag side-effects of floating point operations?
>
> When run on my macbook, the example code on http://en.cppreference.com/w/c
> /numeric/fenv/FE_exceptions does not print all the expected exceptions.
>
> Other examples:
>
> void foo() {
>     fesetround(FE_DOWNWARD);
>     printf("foo downward: %f\n", rint(0.5));
>     fesetround(FE_UPWARD);
>     printf("foo upward: %f\n", rint(0.5));
> }
>
> If compiled with optimization, only one call to rint() is made and the
> result is reused.
>
> void bar(double a, double b) {
>     feclearexcept(FE_INEXACT);
>     a / b;
>     printf("bar %f / %f is %sexact\n", a, b, fetestexcept(FE_INEXACT)?
> "in": "");
> }
>
> The compiler omits the divide as the result is unused.  And so on.
>
> Presumably this has never worked?  And perhaps LLVM is no worse than other
> compilers in this regard?
>
> Is there any appetite to fix it?  What kind of changes would need to be
> made?
>
> Thx,
>
> Will
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160818/8236db5a/attachment.html>