Hello Andreas,
Am 18.03.2023 um 13:32 schrieb Andreas Enge:
Has anyone got any explanation for this behaviour? A compiler error?
Nasal daemons are not a compiler error. Anyway, getting an assembly listing from your gcc version (using the -S switch) would reduce the guesswork. Pass the same compiler flags as the test does. In particular, various options of "-fexcess-precision" flag may alter the generated assembly code and the test outcome.
but this is not even floating point maths - whatever the contents of val and tests[i].result, they should not be changed by a comparison (or an fprintf; I can also make the test work just by adding some printf into the strtod_nol_or_err function that is exercised by this test).
Wild guess: At the first printf, GCC knows that val still resides in some floating point register of your CPU (be it SSE, MMX or x87 registers, depending on the processor models your gcc targets). Hardware floating point registers on x86 are a mess, and they usually do not have the same precision as the IEEE floating point values that are stored in variables (e.g. on the stack or heap), but are slightly more precise. So, at your first printf, gcc will create code that compares that floating point register to the value in the array (loaded into another floating point register of the same type). As the function call will likely clobber some floating point registers (depending on calling convention), for the second printf, gcc will have to create code that loads the value from stack (with reduced precision) back into the floating point register, reducing the precision of the value and making it equal again. Adding "asm volatile" barriers with matching clobbers flags (tbh I don't know by heart what clobbers flags you need to pass to mark *any* x86 floating point registers as clobbered) should also make the nasal deamons disappear, in case tweaking the compiler flags is not an option. Regards, Michael
