(j3.2006) (SC22WG5.5351) [ukfortran] From a colleague
Mon Oct 27 20:56:27 EDT 2014
This discussion seems to be continuing on the J3 list, but for everyone else...
>My colleague wrote:
> I've just learned that at least some compilers will no longer
> support the arithmetic IF statement.
Since that is currently standard-conforming, such a compiler is also not
standard-conforming. Compilers that ignore the standard are (rather obviously)
not going to be affected by whatever *we* decide!
> The reason being that
> there is no good answer as to what this statement should do if
> the value in question is a NaN.
I suspect your colleague is labouring under a misapprehension.
There is, indeed, no good answer as to what this statement should do if the
value in question is a NaN. Which is why you should remove it from your
program. And why it should be removed from the standard.
That does not mean that any compiler will actually rip out its support for the
> And here I thought that
> compiler writers would continue to support all the old features
> out of self interest. But here there seems to be no good
Compilers will "support" it, but you should never use it.
>This colleague has "only" about 170,000 lines of Fortran 77
Right, and arithmetic IF is a Fortran 66 feature that is redundant with Fortran
77, therefore we are talking 2014-1978 = it has been obsolete for 36 years and
formally marked as obsolescent for 2014-1991=23 years.
I don't see why the standard should support broken features that were obsolete
for virtually the entire working lifetime of all current programmers.
Anyway, if NaN's are not an issue (either because you've proved some difficult
mathematical theorems about your code, you have some sophisticated error
handling mechanism, you are running with the Invalid Exception trap enabled, or
you don't care if the bridge falls down/plane falls out of the sky), it is
trivial to replace arithmetic IF with newer alternatives.
After all, if you continue to use arithmetic IF, that's what the compiler is
effectively going to do "under the covers". There are no single machine
instructions that branch to three different labels depending on a floating-point
value. Of course this means that NaN will do different (and maybe impossible)
things on different machines or with different compiler options. Now THAT would
be a problem! At least if you replace it with 1-3 logical IF+GOTO yourself it
will do the same thing.
> code to
>support. He's a semi-retired proprietor of a small business, with no
>staff other than himself to revise his codes so as not to use Arithmetic
If he doesn't know what his code should do with a NaN, I don't see how it is any
fault of the language or the compiler!
>Was it really wise, and especially was it necessary, to delete
Yes, and yes.
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3