Public/Private or gfortran problem?
Chris Bradley
I have a code that fails to compile/link properly with gfortran. Before
I submit a bug report I like to have the newsgroups advice as to whether
this is indeed a bug or simply me misunderstanding the standard.
If I have the following
$cat test3.f90
MODULE TEST3
PRIVATE
CHARACTER(LEN=80) :: TESTCHAR
INTEGER :: TESTINT
REAL :: TESTREAL
COMMON /TESTCOMMON1/ TESTCHAR
COMMON /TESTCOMMON2/ TESTINT
COMMON /TESTCOMMON3/ TESTREAL
END MODULE TEST3
$cat test2.f90
MODULE TEST2
USE TEST3
PRIVATE
CHARACTER(LEN=80) :: TESTCHAR
INTEGER :: TESTINT
REAL :: TESTREAL
COMMON /TESTCOMMON1/ TESTCHAR
COMMON /TESTCOMMON2/ TESTINT
COMMON /TESTCOMMON3/ TESTREAL
PUBLIC TESTCHAR
END MODULE TEST2
$cat test1.f90
PROGRAM TEST1
USE TEST2
WRITE(*,*) TESTCHAR
END PROGRAM TEST1
then when I compile it with gfortran it get the following problem
$gfortran -o test3.o -g -c test3.f90
$gfortran -o test2.o -g -c test2.f90
$gfortran -o test1.o -g -c test1.f90
$gfortran -o test1 -g test1.o test2.o test3.o
test1.o: In function `test1':
/data/test1.f90:6: undefined reference to `__test2_MOD_testchar'
collect2: ld returned 1 exit status
make: *** [test1] Error 1
$ gfortran -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
If I comment out the USE TEST3 line in test2.f90 then all is fine. The
test code also compiles and links without any problems with the intel
and IBM compilers. Given that everything is private in TEST3 then my
understanding is that it shouldn't matter if TEST2 uses it or not? Is
this a compiler bug or my misunderstanding of the use of COMMON blocks
inside PRIVATE modules?
Thanks in advance
Chris
GaryScott
CVF 6.6c likes it with F95 standards compliance checking applied. Not
proof that it's ok, but looks ok to me.
GaryScott
P.S. I think you have to interpret the COMMON definition as equivalent
to a public declaration for those items in COMMON.
michael...@compuserve.com
>
> - Show quoted text -
No, that is not quite the case: variable names in a common block in a
module may be declared to have the private attribute, however, this
does not prevent
associated variables being declared elsewhere through other common
statements ("Fortran 95/2003 Explained", Section 20.2.3). The code in
question looks fine to me.
Regards,
Mike Metcalf
GaryScott
Thanks, yes, I thought that was incorrect shortly after posting.
> module may be declared to have the private attribute, however, this
> does not prevent
> associated variables being declared elsewhere through other common
> statements ("Fortran 95/2003 Explained", Section 20.2.3). The code in
> question looks fine to me.
>
> Regards,
>
> Mike Metcalf- Hide quoted text -
paul.rich...@gmail.com
gfortran-4.1.2. I will post it in Bugzilla tomorrow, if you do not
beat me to it.
Cheers and thanks for the report.
Paul
paul.rich...@gmail.com
> Regrettably, this is a regression, since it worked OK in
> gfortran-4.1.2. I will post it in Bugzilla tomorrow, if you do not
> beat me to it.
Posted as PR38657.
Thanks for the report.
Paul
Chris Bradley
thanks for the comments and thanks to Paul for submitting the bug for me
(I've been away from the computer).
Best wishes
Chris