It turns out that the tests fail on linux on Intel if you add the following code:
void
set_fpu (unsigned int mode)
{
asm ("fldcw %0" : : "m" (*&mode));
}
and then
at the start of main. This (according to https://www.linuxtopia.org/online_books/an_introduction_to_gcc/gccintro_70.html ) sets excess precision to be disabled. This makes it compatible with other platforms that do not support excess precision.
Indeed, the results that I then get from x86 compare to those that I get from a microcontroller platform.
The failed tests seem to indicate that the system sprintf is doing something different. The worst cases appear to be with very small exponents. For example:
Results don't match, format string: %.16e
sprintf(3): [1.6784992078596053e-265] (23)
snprintf(3): [1.6784992078596017e-265] (23)
Results don't match, format string: %.16e
sprintf(3): [1.6784992078596089e-265] (23)
snprintf(3): [1.6784992078596053e-265] (23)
I am a bit puzzled by the fact that the x86 code is using long double and the microcontroller platform is not.
It turns out that the tests fail on linux on Intel if you add the following code:
and then
at the start of main. This (according to https://www.linuxtopia.org/online_books/an_introduction_to_gcc/gccintro_70.html ) sets excess precision to be disabled. This makes it compatible with other platforms that do not support excess precision.
Indeed, the results that I then get from x86 compare to those that I get from a microcontroller platform.
The failed tests seem to indicate that the system
sprintfis doing something different. The worst cases appear to be with very small exponents. For example:I am a bit puzzled by the fact that the x86 code is using
long doubleand the microcontroller platform is not.