Errors with optional arguments

[Ignacio Fernández Galván]

Hi all,

I encountered a couple of errors when trying to use optional arguments in subroutines. First, this one happens when the optional argument is the last of three, but not the only one or the last of two:

==========================================

$ cat test.f90

program test
implicit none
real :: a,b,c

call one(a)
write(6,*) a
call one()
write(6,*) a

call two(a,b)
write(6,*) b
call two(a)
write(6,*) b

call three(a,b,c)
write(6,*) c
call three(a,b)
write(6,*) c

end program test

subroutine one(a)
implicit none
real,optional :: a

if (present(a)) a=0.0

end subroutine one

subroutine two(a,b)
implicit none
real :: a
real,optional :: b

if (present(b)) b=0.0

end subroutine two

subroutine three(a,b,c)
implicit none
real :: a,b
real,optional :: c

if (present(c)) c=0.0

end subroutine three


$ $ gfortran test.f90 ; ./a.out
   0.0000000
   0.0000000
   0.0000000
   0.0000000
   0.0000000
Violación de segmento

==========================================

This other error occurs when using an optional argument in an OMP Reduction clause (is this allowed, anyway?):

==========================================

$ cat test2.f90

program test
implicit none
real :: aa,bb

aa=1.0
bb=0.0

call one(aa)
write(6,*) aa,bb

bb=0.0

call one(aa,bb)
write(6,*) aa,bb

bb=0.0

call one(aa)
write(6,*) aa,bb

end program test

subroutine one(a,b)
implicit none
real :: a
real, optional :: b
integer :: i

a=0.0
if (present(b)) b=1.0
!$omp parallel private(i) reduction(+:a,b)
!$omp do
do i=1,1000000
  a=a+1.0
  if (present(b)) b=b+1.0
end do
!$omp end do
!$omp end parallel

end subroutine one


$ gfortran -fopenmp test2.f90 ; ./a.out
Violación de segmento


$ gfortran test2.f90 ; ./a.out
   1000000.0       0.0000000
   1000000.0       1000001.0
   1000000.0       1000001.0

==========================================

... and, as you see, when not using OMP, the optional argument is somehow being "remembered" the third time the subroutine is called, it should have printed 0.0000000 instead of 1000001.0.

All this was done with the latest binary build in a linux system:

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/todos/Programas/gfortran-20091206/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --disable-shared
Thread model: posix
gcc version 4.5.0 20091205 (experimental) [trunk revision 155016] (GCC)


Is this a known or expected behaviour? Am I doing something wrong? Should I file a bug report?

Thanks,
Ignacio