Re: Procps in core-updates

[Michael Schierl <schierlm@gmx.de>]

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