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