[erlang-bugs] math:exp() erlang bug on SPARC

[Ben Murphy]

I think the issue is with Solaris implementation of exp in libm (i
don't know if it is actually correct or not....):

You can take the code exp.c code from illumos (opensolaris fork)
https://github.com/joyent/illumos-joyent/blob/master/usr/src/lib/libm/common/C/exp.c#L334
and run it on x86 and you will see the same issue. It falls over on:
if (-x > threshold2)

So if you do exp(x) and x < -7.45133219101941108420e+02 then you trigger it


On Thu, Apr 14, 2016 at 12:24 PM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
>
> On Wed, Apr 13, 2016 at 3:46 PM, Matt Keenan <matt.keenan@REDACTED> wrote:
>>
>> Just wanted to report a SPARC specific issue with Erlang.
>
>
> I'm not entirely convinced it is with Erlang, so consider this inquiry.
> Sparc uses a 64bit wide internal representation of IEEE 754 double binary fp
> numbers, whereas the internal representation in x86 is 80 bit wide (due to
> that being the width of the 387 coprocessor back in the day).
>
> exp(-1162.102134881488)
>
> is 2.02048... x 10^-505 which is smaller than the smallest representable
> float. The limit, as x -> -infty is 0 for exp(_), so one would argue that
> the correct output in this case is 0.0.
>
> Erlang simply calls into the C math.h exp function for this, but it does FP
> exception checks around the point. One way to figure out what happens would
> be to get hold of a SPARC machine, write a simple C program doing the same
> and verifying that the SPARC compilers agrees on that one with an x86
> program. I could imagine some way it provokes an FP exception on the SPARC
> architecture, but not on x86 due to the extra bits x86 has in internal
> encoding width.
>
> --
> J.
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>