------- Comment #9 from burnus at gcc dot gnu dot org 2008-08-08 09:50 -------
(In reply to comment #8)
> What does Fortran 2003 have to do with legacy mode? Nothing.
Well, any compiler strives to be standard compliant thus I would expect all of
the compilers to behave *by default* according to the standard (as defined by
the International Organization of Standardization, ISO, and its members such as
ANSI, DIN, BSI, ...).
Relying on anything else is problematic as it might break if you upgrade to a
new compiler version, change to a different compiler or change your system. As
long as a vendor extension or implementation choice is compatible with the
Fortran standard, I think it makes sense that compiler writers try to implement
them in a way compatible with the majority of other compilers. As soon as the
Fortran standard clashes with an implementation choice - even if is the
implementation of e.g. 8 wider spread compilers - the standard wins. (After
all, all major vendors are also on board of the standardization committee,
which means that either those who want to have the "changes" have better
arguments, more compilers behave differently or that the representative was
asleep.)
> So far as I know the GCC compiler is at odds with Solaris, Intel, Vax
It is not at the odds with g77, which is gfortran's ancestor (even though not
code wise). It is also compatible with g95, NAG f95, Open64/openf95 (which is
based on the SGI compiler) and may more compilers. Additionally, the compilers
you mentioned above will move to the Fortran 2003 standard in the future. With
default options your program will then break as well.
For vendors such as Intel the problem is bigger: They have customers which
expect the Fortran 2003 result (like me) and other customers which expect the
behavior of older versions of ifort (like you). Whatever they use as default,
it will break programs and leave angry customers behind.
(Though in case of unit=6 I/O the issue should not be too difficult to trace
down. Relying on zero default initialization, BOZ (where some implementation
choices are at odds with the Fortran 2003 standard) are much harder to trace
down.)
> The behaviour is therefore both unexpected and difficult to track
> down (not even a warning).
I agree that is unexpected, but that is always the case if one relies on
something undefined, where a few vendors choose one solution and the rest
choses different implementations. An example for this are random numbers. If
you call random_seed without any arguments, do you want to have the same random
number sequence every time you run the program or every time a different
sequence? It is not specified in the standard and one can argue for either one.
> This is a serious bug, make no mistake.
It is not. It is a inconvenience - and seemingly a major one for your program -
but not a serious bug.
> It causes existing Fortran 77 code to fail.
It only causes a small fraction of Fortran code to fail, which never was valid
Fortran 77. I have such a program, but there it simply write one more line to
the LOG file instead of to stdout. It is mildly annoying, but does not hamper
the use at all. Your program seems to be one of the few programs which use it
and where this causes a major problem.
> The ubiquitousness of the print*, (or write(*,*)) statement makes fixing
> this bug a priority.
First, while * is used in almost all Fortran programs, the "OPEN(6, file=" is
by far not ubiquitousness.
Secondly, as written it is not a bug but a feature, which relied on some
implementation choice. In any case there will never be a default-warning as the
code is perfectly valid and only clashes with an implementation choice.
Thirdly, if you think that there should be an option to warn (which had to be
turned on explicitly not via -Wall) or an option (flag) to behave differently,
you can open a new bug (Severity: Enhancement), but do not expect that this
will be a high-priority bug. -- Even better: As the source code is available,
we are happy to incorporate patches.
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |schilds at sun dot ac dot za
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
