------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-10-11 16:25 ------- Subject: Re: gfortran .mod files have unusual entries about private common blocks
[ I've added the bug database to the CC list again, this way this discussion will be archived somewhere and can be referenced ] Konstantin Olchanski wrote: > Tobi, I understand how Fortran (<=77) common blocks work, but your > desription of Fortran-90+ common blocks puzzles me. Our code is written > like this: > > foo.cmn: > common /foo/ blah... > > module a > include "foo.cmn" > end module a > > module b > use a > include "foo.cmn" > end module b > > module c > use b > include "foo.cmn" > end module c > > Somewhere between module b and c, the current gfortran becomes > confused and generates bogus errors about size mismatches between > common blocks and invalid variables from the common block. Absoft, Intel > and PathScale compilers accept our code, so I think it is valid Fortran-90. > gfortran barfs, so I assume it is wrong (in a democratic way). This is wrong code, the other compilers are wrong. I only have the draft Fortran 95 standard, but since this restriction also appears in F2K (as Constraint C590) I'm sure this will also be in the final Fortran 95 standard. What it says is this (eliding irrelavant stuff, pp22,23): R550 common-block-object is variable name [ ... ] ... Constraint: A variable-name shall not be a name made accessible by use association. Now, due to your multiple including of the same common line, the same name reappears again and again in a common block, even though it's use associated. This is the violation of the standard I was referring to. Actually, after writing this, and double checking the quote in a book which reproduces the Fortran 90 standard, I see that Fortran 90 doesn't seem to have this connstraint. So maybe the other compilers will refuxe it in some kind of strict mode. > > But I still disblieve you theory that common blocks belogn inside > a module. In the above example, the one common block should be in which > module? How will this common block be shared with g77, C and > C++ compiled code? No, that's not what I'm saying. The thing about common blocks is that they're _not_ in modules. We have to record them to know where in memory a variable will be found -- remember that common storage works differently from other storage. A common variable is replaced to an offset into a common storage, which carries the name of the respective common block. > > (read on) > > >>Say, if you have >>module m >> common /s/ x, y >> private x >>end module >> >>use m >>common /s/ a, b >>y = 2. >>print *,b >>end >> >>This program should print "2.0000". >>This is why we need the information about x >>being in the common block in the main program. (I'm not completely sure if >>symbols which are in a common may be public, and I will verify this, >>but you get >>the point). > > > This is not how Fortran compilers traditionally work. They save no information > about the internal structure of the common block- only the name and size. Indeed, and we record the size by recording the objects that are stored in the common block. Common block are layouted way after module files have been written, and this way the frontend needs no knowledge about how memory is layout in the backend (well, it needs some knowledge to get equivalences right, but that's not the point), for instance your common block can look quite different if derived types are packed or not. > If you have mismatching definitions of common blocks between source > files, you may get a linker warning (global "s" size mismatch) (older > linkers did not complain) and you may see "interesting" effects on variable > values. Most of the time, these are bugs (that is why most programs define > common blocks in header files), but I have seen (ugly) code where it is > done on purpose. Indeed, but when you put common blocks in a module the compiler can do better. Please note that in module m common /c/ i, j private i end module use m i = 4 end The variable i set in the main program will be a local variable, not the variable in the common block, so we get that right. If we add common /c/ x, k j = 2 print *, k to the main program, the compiler needs to know that j is one storage unit into the common block, and therefore it needs to know more about the common block than just its size. The problem you're seeing is that gfortran is quite strict about the standard, and about where common blocks are allowed. It is not wrong (at least wrt to these things, and the bugs I thought I had found yesterday were actually bugs on my side, so I'm quite confident that we get it right) If Fortran 90 code like yours is something we'd like to support (I'm guessing you'd want that :-) we can reopen the bug, mark it enhancement, and maybe add a comment which only contains the things I said about Fortran 90 above, to make it easier to see why it has been reopenened. > P.S. With the two patches (modules/commons and blah_conv_ref_blah) I was able > to compile and link our data reconstruction program (F77+F90+C+C++). Yay! Cool! > It still does not run (argc,argv[] do not work, and then it crashes > in the "namelist" code), so we still have a few gfortran bugs to fix. Is your main program in C or in Fortran? This could explain the issues with argc/argv. And namelists are still in a bad state ... BTW I'd also like to thank you for taking the time to report all these bugs, highly appreciated, Thanks, - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17918
