Balasz, Your code actually also doesn't work on the CentOS 7.4 compilers (gfortran 4.8.5, ld version 2.25.1-32.base.el7_4.2), neither should it as it violates a Fortran 77 rule. In fact, it also fails with the Intel compilers.
What I found on the web: "Variables in blank COMMON blocks may be initialised with READ or assignment statements but not with a DATA statement. The same restrictions apply to named COMMON blocks with one important difference: named COMMON blocks may be initialised in a special nonexecutable subroutine called a BLOCK DATA subprogram." I've attached a tar file with my modifications (a block data subprogram) and a Makefile that compiles three executables in different ways. I've also returned to full Fortran77, so no modules or whatsoever. This does not mean that we do not have a problem though. Or there is still something wrong with my code, or there is indeed something wrong with gfortran or our utilities compiled with EasyBuild. On our cluster Leibniz, with the intel/2017a toolchain (which also includes gcc with gfortran): ln2.le-1222: make clean exe FC=ifort >&/dev/null ln2.le-1223: ./main_prob1 IA = 24 IB = 1 2 3 4 ln2.le-1224: ./main_prob2 IA = 24 IB = 1 2 3 4 ln2.le-1225: ./main_prob3 IA = 24 IB = 1 2 3 4 ln2.le-1226: make clean exe FC=gfortran >&/dev/null ln2.le-1227: ./main_prob1 IA = 0 IB = 0 0 0 0 ln2.le-1228: ./main_prob2 IA = 24 IB = 1 2 3 4 ln2.le-1229: ./main_prob3 IA = 24 IB = 1 2 3 4 So the case where I link with a library which contains a gfortran-generated object file, the output is wrong, but when I link against a library generated with Intel Fortran I actually get the expected output. However, reverting to the default CentOS7.4 compilers: ln2.le-1230: module purge ln2.le-1231: which gfortran /usr/bin/gfortran ln2.le-1232: !make make clean exe FC=gfortran >&/dev/null ln2.le-1233: make ./main_prob1 IA = 24 IB = 1 2 3 4 ln2.le-1234: make ./main_prob2 IA = 24 IB = 1 2 3 4 ln2.le-1235: make ./main_prob3 IA = 24 IB = 1 2 3 4 We now get the expected output in all cases. Regards, Kurt Op 15/02/18 22:11 heeft [email protected] namens Balazs HAJGATO <[email protected] namens [email protected]> geschreven: Dear Easybuilders, I have some problems with fortran linking. It looks that certain versions of fortran does not look for external block data in libraries. If one specifies the object file for the block data then the result is correct. It seems that gfortran <= 4.8 works correctly, but gfortran >=4.9 not works correctly in some cases. bad results (all zeros in the answer): our site with foss/2015b, (GCC 4.9.3), foss/2016a (GCC 4.9.3), foss/2016b (GCC 5.4.0) , foss/2017a (GCC 6.3.0), foss/2017b (GCC 6.4.0), GCCcore 6.4.0, GCCcore 7.1.0 both SL 6 and CentOS 7) UGent foss/2018a (GCC 6.4.0), GCCcore 6.4.0 UCL (Louvain-le-neuve) HMEM GCC 6.3.0 UNamur HERCULES GCC 7.1.0 good results (non zero answers) our site with foss/2015a (GCC 4.9.2), and system compilers GCC 4.4.6 and GCC 4.8.5, singularity/docker ubuntu16.10 GCC 6.2.0, manual build GCC 6.4.0 with pure CentOS 7.4 deps. UBC (Vancouver, ComputeCanada) 5.4.0 UBC (Vancouver, ComputeCanada) 6.4.0 As far as I know, ComputeCanada does not use easybuild provided binutils (although I am not sure), the rest does (although I am not sure in case of UCL and UNamur), so first I thought this might be the problem, but it does not explain why the GCCcore 5+ versions does not work correctly. Then I installed GCC 6.4.0 manually, using purely CentOS 7.4. deps (GMP, MPFR and LIBMPC), and the the compiled program gives the right answer. I do not know how to proceed, and based on the results, I think that there is a problem with the EasyBuild GCC/GCCcore installation, but I do not how where it could be (I do not think that GMP, MPFR, ISL or LIBMPC is the problem, but I am not an expert) Any thoughts? (the sample program along with a compilation script is attached) Sincerely, Balazs
test_common.tar
Description: test_common.tar
