Re: Procps in core-updates
Am Mon, Mar 20, 2023 at 09:02:01PM +0100 schrieb Michael Schierl:
> Seems that you accidentally attached the object file (binary) instead of
> the assembly output. :-)
Hm, I had accidentally written the assembly output to a .o file, and then
apparently accidentally overwritten the file before attaching it :-(
> > The weirdest thing is that actually the value is the integer 123. So it
> > should be stored in any kind of register exactly.
> 123 as a normalized binary floating point number would be
> 1.921875 × 2⁶
> and you would have to represent the mantissa in binary (1.111011₂).
> Still this should fit into most floating point registers easily.
Exactly! 7 bits of mantissa would be enough.
> But possibly the value computed by the algorithm of parsing the number
> resulted in e.g.
> 1.1110110001011₂ × 2⁶
I looked at the algorithm, it uses a Horner scheme
((1*10)+2)*10+3, so everything should fit in every step and be fine.
I mentioned the problem to colleagues, who told me "this is the well-known
GCC bug 323":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
And they pointed me to even crazier things, errors even after casting
floating point numbers to integers in cases where gcc "optimises" the code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
Enjoy the output
z = 0
z is one
coming from
int z = opaque(1) + 0x1p-60 == 1;
printf("z = %d\n", z);
if (z)
puts("z is one");
!
It looks like a quantum computer, z is a superposition of 0 and 1 :)
Andreas
Re: Procps in core-updates
Hello Andreas, Am 20.03.2023 um 15:54 schrieb Andreas Enge: Hello Michael, I am attaching a simplified C file and the corresponding assembly output; which I cannot read, but there are differences between the two invocations of fprintf. Seems that you accidentally attached the object file (binary) instead of the assembly output. :-) The weirdest thing is that actually the value is the integer 123. So it should be stored in any kind of register exactly. 123 as a normalized binary floating point number would be 1.921875 × 2⁶ and you would have to represent the mantissa in binary (1.111011₂). Still this should fit into most floating point registers easily. But possibly the value computed by the algorithm of parsing the number resulted in e.g. 1.1110110001011₂ × 2⁶ which is still 123 when converted back to a 52-bit mantissa, but something ever so slightly larger when treated as an 80-bit float with 64 bits mantissa. Or maybe I'm missing something :-) Regards, Michael
Re: Procps in core-updates
Hi Felix,
--- Original Message ---
On Sunday, March 19th, 2023 at 5:49 PM, Felix Lechner via "Development of GNU
Guix and the GNU System distribution." wrote:
>
>
> Hi Andreas,
>
> On Sat, Mar 18, 2023 at 5:33 AM Andreas Enge andr...@enge.fr wrote:
>
> > FAIL: strtod_nol_or_err("123") != 123.00
>
>
> Can you multiply by "1.0" to force a floating-point comparison, or
> round the other side to the nearest int?
Judging from the function name ("strtod_nol_or_err", which seems in line with
the standard "strtof"/"strtod"/"strtold" conversion functions), the function
returns a double value. Depending on the specific code, it could be
encountering inconsistencies comparing a double to a float (non-double)
constant due to the difference in types' precision.
Cheers,
Kaelyn
>
> Kind regards
> Felix
Re: Procps in core-updates
Hi Andreas,
On Sat, Mar 18, 2023 at 5:33 AM Andreas Enge wrote:
>
> FAIL: strtod_nol_or_err("123") != 123.00
Can you multiply by "1.0" to force a floating-point comparison, or
round the other side to the nearest int?
Kind regards
Felix
Re: Procps in core-updates
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
Re: Procps in core-updates
Am Sat, Mar 18, 2023 at 01:38:48PM -0400 schrieb Leo Famulari: > I recommend trying the latest upstream version, 4.0.3. The Sourceforge > download page points to the new canonical location: I already tried, it does not change anything. If I mess with the package, I would in any case update the version - it requires about 7000 rebuilds, so we may as well use it for an update. > If that doesn't work, I would just disable the test, unless there is > some authoritative upstream opinion about which patch to apply. Sure, I can always do. I am just wondering about how the test failure is even possible... Andreas
Re: Procps in core-updates
I recommend trying the latest upstream version, 4.0.3. The Sourceforge download page points to the new canonical location: https://gitlab.com/procps-ng/procps If that doesn't work, I would just disable the test, unless there is some authoritative upstream opinion about which patch to apply.
