------- Comment #2 from sven dot buijssen at math dot uni-dortmund dot de
2007-12-12 15:04 -------
Having reread the Fortran 95 language spec I don't see why the initial testcase
violates the standard. But I managed to distill a testcase that does not need
recursive functions and still triggers the bug of 'foo' getting implicitly the
SAVE attribute:
--- cut here ---
module demo
implicit none
private
type myint
integer :: bar = 42
end type myint
public :: func
contains
subroutine func(ivalue)
integer, intent(in) :: ivalue
type(myint) :: foo
print *, foo%bar
foo%bar = ivalue
end subroutine func
end module demo
program main
use demo
implicit none
call func(1)
call func(2)
end program main
--- cut here ---
In case this piece of code still violates the standard, I would very much
appreciate a hint where and why exactly it does. (Sorry to waste your time.)
gfortran 4.[1-2].x gives:
$ gfortran -W -Wall -pedantic -std=f95 demo3.f90 && ./a.out
42
1
while one would expect two times '42' as do Intel Fortran 9.x/10.x, PGI 7.x,
Pathscale 3.x, recent g95 versions, Compaq Fortran X5.4A-1684 and Sun Fortran
95 8.3 2007/07/18.
Without the private/public statements gfortran 4.3.x exhibits the same
behaviour. The test case above, however, gives
type(myint) :: foo
1
Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type
'myint'
which seems unrelated to me and for which I probably should submit a new bug
report. I added this information here nonetheless as it might help to trace the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
