Re: pbulk bootstrap: `awk` running into FP overflow during bison build (Grater picture: How to bootstrap pkgsrc / pbulk?)

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Mon, 7 Aug 2023, Mouse wrote:

> >> [...], but I think it would be a reasonable idea to map F_floating,
> >> D_floating and G_floating quantities respectively to the `float',
> >> `double' and `long double' data types.
> 
> Better would be float = F, double = D or G, long double = H.  Better
> from an ideal theoretical perspective, that is; the lack of hardware
> support for H-float could be a problem in practice.

 We already have the "float = F, double = D or G" part implemented in GCC, 
so that's no news.  Adding H for long double would be little effort on the 
GCC side, and the rest is up to libm.  But with little hardware available 
it's probably not worth it even if we add machine instruction emulation.

> >> Not that I have checked in the standard, but having a data type that
> >> narrows the mantissa when converted to a larger type sounds not
> >> especially good :-)
> 
> C99 specifies that "[t]he set of values of the type float is a subset
> of the set of values of the type double; the set of values of the type
> double is a subset of the set of values of the type long double", so
> mapping double to D-float and long double to G-float would be a spec
> violation.  (It's a violation I doubt would matter much in practice,
> mind you, but still strictly a spec violation.)

 Right, I've since checked it too.  So the only legal solution that comes 
to my mind and which solves the issue of programs expecting a wider range 
of the exponent is to define a new ABI and then use multilibs to switch 
between ABIs.

 Still the libm part would be required for the new ABI, and then kernel
and dynamic loader infrastructure so as not to load incompatible modules 
together.

 NB it is only 3 bits of the significand that D_floating and G_floating 
differ by from each other and while I'm told the 3 extra bits are valuable 
to some use cases that do not care about the wider range of the exponent, 
most software prefers the other arrangement, so choosing G_floating over 
D_floating seems like a good compromise nowadays.

> I don't have any more recent C spec on hand to check.

 Drafts are freely available online, see e.g. 
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf> for a version 
from Sep 2022 which is supposed to eventually evolve into C24.

  Maciej