Dear Kurt,
For me, the original code (initt with "MODULE INITT") works on CentOS
7.4 out of the box on both Hydra and Leibniz.
[vsc10002@nic49 180214_test]$ ml purge
[vsc10002@nic49 180214_test]$ uname -a
Linux nic49 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
[vsc10002@nic49 180214_test]$ gfortran --version
GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
[vsc10002@nic49 180214_test]$ ./compile
A = 24
B = 1 2 3 4
[vsc10002@nic49 180214_test]$ ld --version
GNU ld version 2.25.1-32.base.el7_4.2
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
And intel/2017b works as well for the original code (with "MODULE INITT")
Sincerely,
Balazs
On 16/02/2018 10:35, Lust Kurt wrote:
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
--
HPC consultant
HPC/VSC Support and System Administration
Computing Center
ULB/VUB
Avenue Adolphe Buyllaan 91 - CP 197
1050 Brussels
Belgium
