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 Sun, 6 Aug 2023, Mouse wrote:

> > I think it's more likely that an algorithm expects a division by zero
> > or a range overflow to silently produce an infinity or NaN rather
> > than trap.
> 
> Possibly, but I'd expect that to produce a divide-by-zero trap.  Divide
> by zero and floating overflow are distinct when generated by the
> hardware (the both use the "arithmetic exception" SCB slot, but they
> push different type codes).  I don't have a recent VAX trap.c at hand
> to check, but the 5.2 one does draw the distinction:
> 
> 	case T_ARITHFLT|T_USER:
> 		sig = SIGFPE;
> 		switch (frame->code) {
> ...
> 		case ATRP_FLTOVF: code = FPE_FLTOVF; break;
> 		case ATRP_FLTDIV: code = FPE_FLTDIV; break;
> ...
> 		}
> 
> Of course, I also have no specific reason to think that the message
> printed is accurate, just general faith that nobody would commit code
> that maps FPE_FLTDIV into "Floating point overflow".

 Good point, but that leaves a range overflow expecting to produce an 
infinity still a valid possibility.

 Though, hmm, it has struck me that the program might expect the IEEE 754 
exponent range of the double FP type, which raises a question: which of 
D_floating and G_floating format has our port chosen?  If it's G_floating, 
then I'd expect the very narrow difference from IEEE 754 double highly 
unlikely to hit, however with D_floating where the width of the exponent 
is the same as with F_floating, i.e. the single FP type, it's actually 
very likely.

 Overall I think we ought to support both, but it might be a bit tricky on 
the toolchain side, as it's an ABI issue to sort out.  Did any machine 
actually implement H_floating in hardware, or was it only ever emulated?

  Maciej