Bug 5757 – std.math: exp, expm1, exp2 return 'inf' when no asm.

The fallback if D_InlineAsm is not a version predicate (true for non-x86 arch's) is not calling the appropriate libm functions for the precision we require (need 80bit precision). Regards diff --git a/std/math.d b/std/math.d index e5591e7..6bdb3e7 100644 --- a/std/math.d +++ b/std/math.d @@ -967,7 +967,7 @@ real exp(real x) @safe pure nothrow // and exp2 are so similar). return exp2(LOG2E*x); } else { - return core.stdc.math.exp(x); + return core.stdc.math.expl(x); } } /// ditto @@ -1133,7 +1133,7 @@ L_largenegative: ret; } } else { - return core.stdc.math.expm1(x); + return core.stdc.math.expm1l(x); } } @@ -1315,7 +1315,7 @@ L_was_nan: ret; } } else { - return core.stdc.math.exp2(x); + return core.stdc.math.exp2l(x); } }

(In reply to comment #0) > The fallback if D_InlineAsm is not a version predicate (true for non-x86 > arch's) is not calling the appropriate libm functions for the precision we > require (need 80bit precision). Tricky. On most systems (such as OSX), those functions either don't exist, or just call the 64 bit versions. Even in cases when they do exist, they are usually implemented incorrectly. Have you found 80-bit systems where they pass all the unit tests?

Even if they're not totally correct, I doubt (correct me if I'm wrong) that they're worse than the 64-bit versions. The origin of this bug report was trying to get std.mathspecial working on GDC, which doesn't have inline ASM and has to use the fallback functions. For fixing this immediate issue, they may be good enough.

GDC somewhat a bit exceptional, as there's both library functions and it's own internal real_t floating point emulation routines available (which is not exactly IEEE 754 compliant, but is close to the description of characteristics of floating types in the ISO C99 standard), etc... And there's call optimisation and constant folding which means if the values are known at compile-time, then most calls would have been evaluated away. (ie: logN(expN(x)) => x) And I'm sure both GCC and libc aren't always quite what the DMD unittests expect anyway. I know of at least 1 'off-by-one' math unittest that fails because of GCC backend truncates rather than rounds the value from real to double, and another where 1.5 * 10 makes 15.0000000001 - or something to that effect when formatted into a string literal. In any case, I'm more concerned about not hurting the systems that *do* have 80-bit math functions. The only other systems out there I can think of that have it is IA64 - which I have no hardware (though David's already mentioned that there's yet no IASM for for 64bit on GDC anyway. :) Regards

(In reply to comment #3) > GDC somewhat a bit exceptional, as there's both library functions and it's own > internal real_t floating point emulation routines available (which is not > exactly IEEE 754 compliant, but is close to the description of characteristics > of floating types in the ISO C99 standard), etc... > And there's call optimisation and constant folding which means if the values > are known at compile-time, then most calls would have been evaluated away. (ie: > logN(expN(x)) => x) > > And I'm sure both GCC and libc aren't always quite what the DMD unittests > expect anyway. I know of at least 1 'off-by-one' math unittest that fails > because of GCC backend truncates rather than rounds the value from real to > double, and another where 1.5 * 10 makes 15.0000000001 - or something to that > effect when formatted into a string literal. > > In any case, I'm more concerned about not hurting the systems that *do* have > 80-bit math functions. The only other systems out there I can think of that > have it is IA64 - which I have no hardware (though David's already mentioned > that there's yet no IASM for for 64bit on GDC anyway. :) > > Regards Fair enough. AFAIK the only other system with 80-bit reals is Motorola 68K, but the Freescale(?) upgrades to those processors only have 64 bit. So it's probably a legacy system even for embedded processors, and won't ever have much D presence even in the most optimistic scenario.

Relevant pull request has been merged: https://github.com/D-Programming-Language/phobos/pull/770