------- 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