http://d.puremagic.com/issues/show_bug.cgi?id=5757
--- Comment #4 from Don <clugd...@yahoo.com.au> 2011-03-21 10:58:35 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------