Re: Procps in core-updates

[Andreas Enge <andreas@enge.fr>]

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.111011000000000000000000000000000000000000000000000001011₂ × 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