[maarten-boot]

• Problem: cemcom.ansi keeps float constants in flt_arith's 64-bit mantissa,
  folds them at that precision and rounds to the target type only when it writes
  them out. A folded constant could then differ from the same computation at
  run time: in a probe of 300 random pairs, 11-39% of folded + - * / results
  (double and float) were 1 ulp off. 0.1 + 0.2 gave the double nearest 0.3,
  not 0.30000000000000004. A float constant also kept 64 bits, so
  (double)0.1f was the double 0.1 and 0.1f == 0.1 was true.
• flt_arith (commit 2): add, sub, mul and div keep what does not fit as a
  sticky lowest bit (round to odd): the bits shifted out of the smaller operand
  in add/sub, the lower half of mul's 128-bit product (was rounded half-up),
  div's remainder (was dropped). New flt_rnd(e, bits, emin) rounds to bits
  bits, to nearest and ties to even, with subnormal numbers below 2^emin.
  With operands and result rounded by flt_rnd, a result is what IEEE
  arithmetic gives. Documented in flt_arith.3.
• cemcom.ansi (commit 3): every float constant is rounded to its type with
  flt_rnd(): a literal, a folded result, an integer converted to a floating
  type, and a conversion between floating types. A 4-byte type is IEEE single
  and an 8-byte type IEEE double, subnormal numbers included. For targets
  without IEEE floating point, the new -Vm<n> gives the mantissa bits of an
  8-byte type; pdpv7 (PDP-11 floating point, 56 bits) uses -Vm56. Documented
  in cemcom.ansi.1.
• flt_str2flt (commit 3): negative exponents were applied by multiplying
  with reciprocal powers of ten, which is not exact; with the sticky bit even
  1.0 came out as slightly more than 1, and an exact tie like
  9007199254740993.0 rounded the wrong way. It now divides by the exact powers
  10^0 to 10^27, and digits that do not fit in 64 bits set the sticky bit
  instead of being dropped. (A literal with more than 19 significant digits that
  is exactly a tie is still judged on its first 19 digits.)
• Tests:
  • modules/src/flt_arith/ieeetest.c, rule modules/src/flt_arith+test, part
    of all (not on Windows): 1,580,135 random double and float operations
    (subnormal results, exact results and ties included) against the host's
    IEEE arithmetic. The old add, mul and div give 3, 24 and 38 wrong results.
  • tests/plat/floats/constfold,e,.c in the floats set (run on linuxppc):
    folded constants compared with the same expressions computed at run time,
    and with exact values: + - * / of double and float, float precision of
    float constants, 0.1 + 0.2 == 0.30000000000000004, ties rounded to even
    and subnormal results. With the compiler before this PR, 20 of its 26
    checks fail. Operands are plain globals, not volatile: the powerpc ncg
    table has no pattern for the nop cemcom.ansi emits after a volatile
    access (a separate fix).
• linuxppc emulator (commit 1): constfold is the first test that
  multiplies, or does single-precision arithmetic, at run time on linuxppc,
  and the emulator (plat/linuxppc/emu/instructions.dat) could not run it.
  fmul was decoded as X-form with FRB, but it is A-form with FRA and FRC
  (as the assembler, mach/powerpc/as/mach3.c, encodes it): any multiply
  with FRC not f0 stopped with "unimplemented instruction", and one that
  matched computed FRA × FRB. fadds, fsubs, fmuls and fdivs
  (opcode 59) were missing; they compute in double and round to float,
  which is exact for these operations.
• Not changed: the back ends' float_cst (h/con_float) still rounds
  half-up when it converts the constant text; the constants it now gets are
  already rounded, so that has no effect on IEEE targets. The Modula-2 front end
  folds with flt_arith too and is not changed here.

🤖 Generated with Claude Code

[davidgiven]

Merged; thanks!