[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

["sven dot buijssen at math dot uni-dortmund dot de" <gcc-bugzilla@gcc.gnu.org>]

------- 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