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

[John Dallman]

In article <6c941c3b-a6b7-42cc-bfe6-8716ec24e386n at googlegroups.com>,
xyzzy1959 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. 

MSVC and GCC still respect trap semantics, for now. 

John