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

[John Reagan]

On Tuesday, December 1, 2020 at 8:07:33 AM UTC-5, Simon Clubley wrote:
> On 2020-11-30, John Dallman <j... at cix.co.uk> wrote: 
> > 
> > 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. 
> >
> Would declaring the variables volatile have avoided this reordering ? 
> 
> And talking of volatile, I wonder if John has encountered any cases 
> with LLVM where variables now need to be declared volatile where they 
> did not need to be with the DEC compilers.
> Simon. 
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP 
> Walking destinations on a map are further away than they appear.

You've asked that question before.  It ended up in a long and twisted thread (as most do here at c.o.v).

So all compilers (DEC, gcc, clang/LLVM, IBM, etc.) all perform their own unique set of optimizations.  Some are classic compiler optimizations and some are vendor-specific and might vary based on chip set (ie /ARCH or /OPT=TUNE).   And with the various command line options, the permutations of optimizations that might be applied are unbounded.

In my opinion, "volatile" is a place where you have written a technically illegal program that did not perform as expected due one or more optimizations making assumptions that your program was legal.  Illegal programs have undefined behavior, but instead of saying "turn off all optimizations and deal with it", the language provides "volatile" as a way to tell the compiler that operations on a "volatile variable" do not follow the language specification as an attempt to preserve as much performance as possible.

To answer your question directly, no, I've never seen a place where I would need to now use volatile with LLVM than with DEC C, but my experience is limited.  I don't know all the optimizations in LLVM, how they are applied, etc.  I can barely wrap my head around all the optimizations in GEM.

Your question is really: Are there illegal programs that work "correctly" with DEC C without using volatile that will not work correctly with LLVM?  Who knows.  The number of illegal programs are infinite.  Could there possibly be one that works accidentally on VAX, Alpha, Itanium with GEM but not with LLVM on x86 (or ARM or PPC or Apple M1 or some quantum computer)?  Probably.