[Info-vax] Ada x86 (was Rdb/x86)

[John Reagan]

On Monday, November 30, 2020 at 2:05:16 PM UTC-5, John Dallman wrote:
> In article <6c941c3b-a6b7-42cc... at googlegroups.com>,
> xyzz... at gmail.com (John Reagan) wrote: 
> 
> > That's the direction I would go. You might end up with the entire 
> > gcc toolchain. There have been reports with VMS support going away 
> > so it might have to come back.
> Bringing back the GCC toolchain might be a good idea anyway. I've 
> remembered an LLVM feature that caused me trouble a few years back, which 
> may surprise people used to the DEC compilers. 
> 
> With GCC, and AFAIK with the DEC compilers, one can enable floating-point 
> traps, and get sensible results, trapping when you divide by zero, 
> overflow or try an invalid operation, such as sqrt(-1.0). 
> 
> GCC is well aware that floating-point operations may cause traps, and its 
> optimiser limits the rearrangement of code so that you don't get spurious 
> ones. For example if you have: 
> 
> double a, b; 
> ... 
> if ( b < really-small-number) 
> a = 0.0; 
> else 
> a = 1.0 / b; 
> 
> GCC won't move the divide out from under the test that guards against 
> divide-by-zero. 
> 
> LLVM, in contrast, explicitly assumes that floating-point traps will 
> never be enabled, and regards this as obvious, not mentioning the point 
> in its documentation AFAICS. If it has compiled the above code, it may 
> well execute the divide before it knows if the guard condition is true. 
> If that happens, and floating-point traps are enabled, you'll get a trap 
> /every time/ the code is executed with b = 0.0. I hit this problem on x86 
> macOS a few years back, and had to give up using floating-point traps on 
> that platform. 
> 
Not true anymore.  LLVM has added support for all of those trapping modes to match gcc.  And including FENV support in clang.