🚀 go-pugleaf

           I said:
>    1. The question is not what fortran requires but what IEEE imple-
>mented in fortran requires.  One of the problems with IEEE's infs and
>NaNs is that they do not fit well with fortran.
           Robert Firth said:
Yes, that's the problem.  The Fortran standard describes the implementation
of arithmetic expressions in terms of the "mathematical" rules, that is,
the mathematical properties of real numbers.  It is the business of the
implementation to provide a reasonable approximation that, as far as
possible, obeys those rules.  If it fails to do so, i's not a legitimate
"fortran machine" and shouldn't claim to support ANSI F-77.
But a language implementation must follow the standard.  That is the
whole point of standards, after all, that they circumscribe the
permissible implementations.  You can't correct bogus hardware by
writing a bogus compiler.

           Clearly it would be possible to write a compiler for an IEEE
machine which performed all floating point operations by simulating IBM
hex arithmetic (for example) using fixed point instructions.  Such a
compiler might obey the fortran standard.  However it would be ludicrous
to claim it was obeying the IEEE floating point standard.
           Are you saying it is impossible to write a compiler which
simultaneously obeys the fortran standard and the IEEE floating point
standard?  Are you saying the fortran standard forbids floating point
models which include infs?  Do you plan to claim your compiler complies
with the IEEE standard?
           This thread started with my claim that it is expensive for
compilers to comply with the IEEE standard.  I do not claim it is im-
possible.
           I said:
>        Do you replace 0*x with 0 when compiling without optimization?
>I think that if a (legal) program behaves differently when compiled with
>and without optimization that then the compiler is broken.  Perhaps you
>disagree.
           Robert Firth said:
Yes, I disagree.  The issue is the relevance of the difference.  Is a
compiler broken because an optimised program runs faster?  That's a
difference in behaviour, but you presumably think it an acceptable one.
Likewise, if a program transformation is permitted by the standard, a
compiler is entitled to apply that transformation; it is the responsibility
of the programmer to be aware which transformations are legal and not
assume any of them won't happen.

           To clarify I was not referring to timing type differences.
Perhaps I should have said it is undesirable for a program to behave
differently when compiled with and without optimization regardless
of whether this is technically permitted by the standard.  (Actually
I think it would desirable for the standard to exactly specify the
behavior of any legal program but apparently it does not.)  An example
may explain why I believe this.  Consider an user with a 100000 line
fortran package.  It works fine when compiled on other machines (with
and without optimization).  It works fine when compiled with your
compiler without optimization.  However it fails when compiled with
your compiler with optimization.  I believe it will difficult to con-
vince this user that the bug is in his package and not in your compiler
whatever the technical validity of your position
                       James B. Shearer