[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #12 from tobi at gcc dot gnu dot org 2008-08-10 20:43 --- The GFORTRAN_STDOUT_UNIT environment variable mentioned above should make your life a lot easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #11 from schilds at sun dot ac dot za 2008-08-09 07:27 --- Jeez! After reading what all of you have said ... I see this code does actually do something as crazy (and simple) as set the logical unit number for a file to 6, in a subroutine (when I had thought they had only done writes). Yes, this is a known Fortran issue from way back. I apologise profusely for wasting your time in the manner I have. Again, I apologise. P.S. If it makes you feel better, just think of the task I have ahead of me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #8 from schilds at sun dot ac dot za 2008-08-08 08:31 --- What does Fortran 2003 have to do with legacy mode? Nothing. So far as I know the GCC compiler is at odds with Solaris, Intel, Vax, you name it. All of these allowed you to touch unit 6 without affecting the print*, (or write(*,*)) statement. The behaviour is therefore both unexpected and difficult to track down (not even a warning). This is a serious bug, make no mistake. It causes existing Fortran 77 code to fail. It's wasted a lot of my time and, no doubt, a lot of other, good peoples' too. The ubiquitousness of the print*, (or write(*,*)) statement makes fixing this bug a priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- 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
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #10 from kargl at gcc dot gnu dot org 2008-08-08 15:57 --- (In reply to comment #8) What does Fortran 2003 have to do with legacy mode? Nothing. You are aware that Fortran 2003 is backwards compatible with Fortran 77, right? So far as I know the GCC compiler is at odds with Solaris, Intel, Vax, you name it. All of these allowed you to touch unit 6 without affecting the print*, (or write(*,*)) statement. The behaviour is therefore both unexpected and difficult to trackdown (not even a warning). Then by all means use one of those compilers. This is a serious bug, make no mistake. Yes, it is a serious bug in your code. So, fix it. It causes existing Fortran 77 code to fail. No, it does not. You are invoking processor dependent behavior. Whatever results is correct. It's wasted a lot of my time and, no doubt, a lot of other, good peoples' too. The ubiquitousness of the print*, (or write(*,*)) statement makes fixing this bug a priority. I seriously doubt that this issue has wasted a lot of other peoples' time. You're only person in the 6 year history of gfortran to whine about it. If anything, you're wasting the time of the gfortran developers. You know, those good people that have actually given the option of of a free Fortran compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #6 from schilds at sun dot ac dot za 2008-08-07 19:07 --- This is a serious bug, make no mistake. It causes existing Fortran 77 code to fail. It's wasted a lot of my time and, no doubt, a lot of other, good peoples' too. The print*, (or write(*,*)) statement certainly _IS_ standard Fortran 77 and its ubiquitousness should make fixing this bug a priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-07 19:48 --- The print*, (or write(*,*)) statement certainly _IS_ standard Fortran 77 and its ubiquitousness should make fixing this bug a priority. The * is standard Fortran 66 to 2008, however, its interpretation was not well-defined before Fortran 2003. You rely on an implementation choice of a certain compiler and not on the standard. Even worse: With Fortran 2003 your interpretation is opposite to what is written in the standard, which means that gfortran will not change. * * * May I quote from the Fortran 2003 standard (9.4 File connection): An asterisk identifies particular processor-dependent external units that are preconnected for formatted sequential access (9.5.3.2). These units are also identified by unit numbers defined by the named constants INPUT_UNIT and OUTPUT_UNIT of the ISO_FORTRAN_ENV module (13.8.2). That is what gfortran does: INPUT_UNIT is 5, OUTPUT_UNIT is 6 and ERROR_UNIT is 0, the numbers are extremely popular choices though not defined in any Fortran standard. Note especially the word PRE-CONNECTED. The connection of these units can be changed via 9.4.5 The OPEN statement An OPEN statement initiates or modifies the connection between an external file and a specified unit. [...] If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. Thus if one does open(6,file=foo.dat) one changes the connection of unit 6 to point to foo.dat instead of to standard out. Since OUTPUT_UNIT now points to foo.dat, also unit=* (for PRINT/WRITE) points to foo.dat * * * It might be annoying that your old program does not work, but it was never standard conform (at least not to the ISO Fortran 77/90/95/2003/2008 standard) but it relied on a particular implementation choice which is incompatible with the Fortran 2003 standard. Once compiler which treated UNIT=* and UNIT=6 differently was the Intel Fortran compiler, ifort alias ifc. But newer versions follow the Fortran 2003 standard, even though they offer the option: -assume old_unit_star The READs or WRITEs to UNIT=* go to stdin or stdout, respectively, even if UNIT=5 or 6 has been connected to another file. (Older version connected * to negative units, if I recall correctly, thus * was something like -2 (guessed number) and thus 6 and '*' could be connected to different files - both were preconnected to stdout.) Intel introduced that option to be compatible with older version of ifort, which have behaviours which clash with newer Fortran standard. As gfortran (and not even its predecessor g77) had never implement it in a F2003 incompatible way, there is no reason to implement such option, especially as most of the time such programs are not really broken, only the output goes to the wrong place. * * * As a general advice: For file I/O one should use UNITs 10 to make (relatively) sure they do not clash with the INPUT/OUTPUT/ERROR_UNIT of a given compiler; with Fortran 2008 one can let OPEN do the job to assign a free unit [not yet implemented in gfortran]. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-16 14:10 --- Done thusly :-) BTW the directions discussions on comp.lang.fortran turn are fun. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 11:36 --- read *, print_to_file if (print_to_file) then open(6,file=stdout) end if Is this possible with ifort? I haven't found anything like that. The discussion on comp.lang.fortran showed that F 2003 has a ISO_FORTRAN_ENV with the predefined named constants INPUT_UNIT and OUTPUT_UNIT, which can be manipulated by the user and which do affect * when they are opened, closed etc. gfortran's current treatment of unit 6 (and, I presume, 5) mirrors this behavior. So, I guess this must the the Right Thing to do. An INVALID resolution for this bug is therefore OK with me. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-15 12:30 --- Subject: Re: opening unit 6 messes up print Thomas dot Koenig at online dot de wrote: My thinking is that writing to * (or PRINTing) should go to standard output, and that unit 6 just happens to be a convention for a preconnected unit that does the same thing. I really don't think this is worth doing, as we have the evironment variable I pointed you to. So if the user really does want to use unit 6 for some other purposes than stdout, he is free to do so, and so the status quo doesn't prevent anybody from doing anything. I also think that it is a good thing that there's a way of redirecting * output to a file: say, the user wants to do something like: read *, print_to_file if (print_to_file) then open(6,file=stdout) end if Is this possible with ifort? - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-15 08:45 --- (In reply to comment #1) I think that's what intended That's what's for discussion :-) g77 behaves the same way. I think this is a bug, too. My thinking is that writing to * (or PRINTing) should go to standard output, and that unit 6 just happens to be a convention for a preconnected unit that does the same thing. ifort, for example, does things differently: $ cat open2.f open(6,file=foo.dat) print *,hello, world end $ ifort open2.f $ ./a.out hello, world $ ifort -V Intel(R) Fortran Itanium(R) Compiler for Itanium(R)-based applications Version 8.1Build 20041123 Package ID: l_fc_pc_8.1.023 Copyright (C) 1985-2004 Intel Corporation. All rights reserved. ifort: Command line error: no files specified; for help type ifort -help Does the Fortran standard say anything that messing with unit 6 can be bad news for unit * ? I have marked the bug as enhancement with this. -- What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-14 22:19 --- I think that's what intended, g77 behaves the same way. I'm somewhat torn between INVALID and WONTFIX. If the user wants to use unit 6 for something else, and still have PRINT * print to the console, he can preconnect stdout to some other unit via the GFORTRAN_STDOUT_UNIT environment variable. -- What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
