As reported by Jack Howarth http://gcc.gnu.org/ml/fortran/2007-11/msg00122.html Analysis by Walter Spector: a) http://gcc.gnu.org/ml/fortran/2007-11/msg00131.html Ah - the old "put block data in a library, and use EXTERNAL to make sure it gets linked in" trick. Many compilers have gotten this wrong over the years, because it is kinda on the edge of being required by the Standard (any of them). On my cygwin system, g77 and g95 get it right and gfortran gets it wrong. See below. While F90 modules fixed this problem by obsoleting BLOCK DATA and COMMON, quite a number of older library packages depend on this working. Walter $ cat testsub.f SUBROUTINE TESTSUB EXTERNAL BDTEST COMMON/TEST/WK INTEGER WK PRINT *,'TESTSUB: WK = ',WK, '...it should be 20' RETURN END $ g77 -c testsub.f $ nm testsub.o 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 t .text 00000004 d ___g77_cilist_0.1 00000000 d ___g77_forceload_0.0 U _bdtest_ <<<< This references the BLOCK DATA U _do_lio U _e_wsle U _s_wsle 00000010 C _test_ 00000000 T _testsub_ $ gfortran -c testsub.f $ nm testsub.o 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 t .text <<<< Missing a reference to _bdtest_ here U __gfortran_st_write U __gfortran_st_write_done U __gfortran_transfer_character U __gfortran_transfer_integer 00000010 C _test_ 00000000 T _testsub_ ***************************************************************++ b) http://gcc.gnu.org/ml/fortran/2007-11/msg00132.html The other half of this issue is on the BLOCK DATA side. There has to be an entry point that the linker can find: $ cat testbd.f BLOCKDATA BDTEST COMMON/TEST/WK INTEGER WK DATA WK/20/ END $ gfortran testbd.f -c $ nm testbd.o 00000000 b .bss 00000000 d .data 00000000 t .text 00000000 B _bdtest_ <<<< gfortran creates a BSS section 00000000 D _test_ $ g77 -c testbd.f $ nm testbd.o 00000000 b .bss 00000000 d .data 00000000 t .text 00000000 T _bdtest_ <<<< g77 creates a TEXT entry (even though no code exists) 00000000 D _test_ $ Again, while there used to be debates about whether the Standard required this to work, many older packages depend on it.
First, the problem is described, and a full test case available, at: http://www.ncl.ucar.edu/Download/build_from_src.shtml#CompilersNeeded Second, I am not sure if part b (changing the name from BSS to TEXT) is strictly needed. On my cygwin system, if I compile the block data with gfortran (getting the BSS version), and the remainder of the test case with g77, everything works fine. However I can well imagine that linkers on other architectures may work differently.
Created attachment 14610 [details] assembly file generated from testsub.f on i686-apple-darwin9
Created attachment 14611 [details] assembly file generated from testsub.f on i386-redhat-linux (Fedora 8)
As requested by Mike Stump, i've uploaded the assembly files generated with -S for the testsub.f source file of blockdata_test for both i686-apple-darwin9 (which fails to pass) and i386-redhat-linux (which passes the block data tests).
Created attachment 14613 [details] assembly file generated from testbd.f on i686-apple-darwin9
Created attachment 14614 [details] assembly file generated from testbd.f on i386-redhat-linux (Fedora 8)
Added assembly files from testbd.f for i386-redhat-linux and i686-apple-darwin9.
Apparently there are two distinct ways to make this work, either, output a reference to bdtest, or ensure that the linker tries to resolve commons from libraries. Linux uses the later approach. To be portable, gfortran needs to generate the reference to bdtest on those platforms that need it. Darwin would be one such system. I've filed radr://5613343 need to search for definitions for common symbols so we won't need such help at some point.
Created attachment 14644 [details] assembly file generated from testbd.f from g95 on i386-darwin9
Created attachment 14645 [details] assembly file generated from testsub.f from g95 on i386-darwin9
In case this helps prove Mike's hypothesis of the alternate fix to this problem (outside of the patching the darwin linker), I've uploaded the assembly files for testbd.f and testsub.f generated on i386-apple-darwin9 with g95 0.90 compiled against a patched gcc 4.0.3. The blockdata_test all pass with g95 on darwin. I should note that on Macintel we get warnings of the form... g95 -o main.init main.o libtestinit.a ld: warning for symbol _test_ tentative definition of size 16 from libtestinit.a(testsub.o) is being replaced by a real definition of size 4 from libtestinit.a(testbd.o) and g95 -o main.bad main.o libtest.a ld: warning for symbol _test_ tentative definition of size 16 from libtest.a(testsub.o) is being replaced by a real definition of size 4 from libtest.a(testbd.o) which I believe are due to intel darwin specific changes that were never backported out of gcc 4.2 to gcc 4.0.x branch. However, I think these warnings are non-critical.
Yes, the second set contains: _U0.457: .long _bdtest_ which is the part the makes the whole thing work on systems like darwin.
For testsub.f, g95 creates (for "EXTERNAL BDTEST"): static void * U0 = bdtest_; which shows up as: U bdtest_ same for ifort. While sunf95 and openf95 have bdtest_ in the dump. And for the BLOCK DATA g95 creates: bdtest_ () { static int4 wk; } whereas gfortran does not create any dumpable tree. The .o file of gfortran contains: 0000000000000000 B bdtest_ whereas g95, ifort, sunf95, openf95 have: 0000000000000000 T bdtest_
Does anyone have access to other platforms to see if blocktest_data breaks when compiled with gfortran on anything other than Darwin and Cywin?
(In reply to comment #13) > For testsub.f, g95 creates (for "EXTERNAL BDTEST"): > static void * U0 = bdtest_; > which shows up as: > U bdtest_ > same for ifort. While sunf95 and openf95 have bdtest_ in the dump. I meant: While sunf95 and openf95 do not have "bdtest_" in "nm *.o" at all.
It appears that the Darwin9 linker will be modified to handle this issue as the linux linker does in the next Developer Tools update. However it is very unlikely Darwin8's cctools will ever see such a fix. With that in mind, I would be more than happy to test in any proposed patch for gcc trunk which would cause the entry point for the common block to be emitted for testsub.f and testbd.f so that Darwin8 can have the same effective functionality as Darwin9.
Jack, did this problem go away on Darwin?
I have run the tests in comment #1 and main.bad main.init still fail on i686-apple-darwin9.
pr42568 looks like a duplicate of this one. Note that the issue seems fixed on darwin10.
(In reply to comment #19) > pr42568 looks like a duplicate of this one. > > Note that the issue seems fixed on darwin10. > This issue was radr://5613343 and has been fixed for darwin10 and later.
> This issue was radr://5613343 and has been fixed for darwin10 and later. Confirmed and it seems that it is also fixed by the latest version of Xcode for darwin9. So I am closing this PR as FIXED leaving pr42568 open (WAITING) for CYGWIN.