Hello,
My version of PGI is:
lnx: pgf95 -V
pgf95 7.2-4 32-bit target on x86 Linux -tp p7
Consider the following test program:
module app
implicit none
! Define data type with *DEFAULT INITIALISATION*
type, public :: var_type
private
integer :: i = 0
real :: x = 0.0
end type var_type
contains
subroutine sumvar(i,x,var,z)
integer , intent(in) :: i
real , intent(in) :: x
type(var_type) , intent(out) :: var ! *** INTENT(OUT) ***
logical, optional, intent(in) :: z
if (present(z)) then
if (z) then
var%i = 0
var%x = 0.0
end if
end if
print *, var
var%i = var%i + i
var%x = var%x + x
end subroutine sumvar
subroutine printvar(var)
type(var_type), intent(in) :: var
print *, var
end subroutine printvar
end module app
program testapp
use app
implicit none
integer :: i
real :: x
type(var_type) :: var
print *, 'Test with NO explicit zero..'
i=1; x=1.0; call sumvar(i,x,var); call printvar(var)
i=2; x=2.0; call sumvar(i,x,var); call printvar(var)
i=3; x=3.0; call sumvar(i,x,var); call printvar(var)
print *, 'Test WITH explicit zero..'
i=1; x=1.0; call sumvar(i,x,var,z=.true.); call printvar(var)
i=2; x=2.0; call sumvar(i,x,var,z=.true.); call printvar(var)
i=3; x=3.0; call sumvar(i,x,var,z=.true.); call printvar(var)
print *, 'Should the following even compile?'
print *, var
end program testapp
When I compile and run the above I get the following:
lnx: pgf95 -Mstandard test_pgi_incorrect_save.f90
lnx: a.out
Test with NO explicit zero..
0 0.000000
1 1.000000
1 1.000000
3 3.000000
3 3.000000
6 6.000000
Test WITH explicit zero..
0 0.000000
1 1.000000
0 0.000000
2 2.000000
0 0.000000
3 3.000000
Should the following even compile?
3 3.000000
It would appear that the contents of the derived type dummy argument are SAVE’d across calls to the module subroutine “sumvar”. The behaviour of the code should be the same whether or not the optional argument “z” is set to explicitly zero the dummy arg contents since the derived type definition includes default initialisation.
Unless this behaviour can be fixed via a compiler switch (-Mnosave doesn;t have any effect), I believe this indicates a (rather serious, IMO) compiler bug for this particular version.
Additionally, the very last “print *, var” in the main program probably shouldn’t even compiles.
For reference here is the same result when I compile with a relatively recent version of gfortran:
lnx: gfortran --version
GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]
lnx: gfortran -std=f95 test_pgi_incorrect_save.f90
test_pgi_incorrect_save.f90:47.14:
print *, var
1
Error: Data transfer element at (1) cannot have PRIVATE components
Correcting the main source and trying again:
lnx: gfortran -std=f95 test_pgi_incorrect_save.f90
lnx: a.out
Test with NO explicit zero..
0 0.00000000E+00
1 1.00000000
0 0.00000000E+00
2 2.0000000
0 0.00000000E+00
3 3.0000000
Test WITH explicit zero..
0 0.00000000E+00
1 1.00000000
0 0.00000000E+00
2 2.0000000
0 0.00000000E+00
3 3.0000000
My Nov.11 version of g95, and my 5 year old version of Lahey lf95 also produces the same result as gfortran.
Section 4.4 of the Fortran 95 standard (Derived types) states
Default initialization is specified for a component of an object of derived type when initialization appears in the component declaration. The object will be initialized as specified in the derived type definition (14.7.3, 14.7.5) even if the definition is private or inaccessible. Default initialization applies to dummy arguments with INTENT (OUT). Unlike explicit initialization, default initialization (4.4.1) does not imply that the object has the SAVE attribute. If a component has default initialization, it is not required that default initialization be specified for other components of the derived type.
Section 5.1.2.3 of the Fortran95 standard (INTENT attribute) states:
The INTENT (OUT) attribute specifies that the dummy argument shall be defined before a reference to the dummy argument is made within the procedure and any actual argument that becomes associated with such a dummy argument shall be definable. On invocation of the procedure, such a dummy argument becomes undefined except for components of an object of derived type for which default initialization has been specified.
I think those two quotes indicate quite clearly that the pgi f95 compiler is not doing the correct thing. Any comments?
cheers,
paulv