2008/7/21 Peter W. Draper <[log in to unmask]>:
> On Mon, 21 Jul 2008, David Berry wrote:
>
>>> Hmm, not convinced there's a need for any of this. As far as I can see
>>> SLALIB Fortran doesn't use COMMON blocks or explicitly SAVE'd variables,
>>> so
>>> shouldn't it be perfectly reentrant already?
>>
>> I thought all Fortran local variables were allocated statically?
>
> No, you are supposed to use SAVE to get static variables. Some compilers do
> this by default for all local variables, but I didn't think that was true
> for the GNU variants. To get SAVE'd variables with those you needed:
>
> -fno-automatic
> Treat each program unit as if the "SAVE" statement was specified
> for every local variable and array referenced in it. Does not
> affect common blocks.
>
> (g77), which is one of the reasons we spent so much time looking for
> uninitialised variables when porting from VMS. Now what has me worried is
> that I cannot see the similar option for g95, although gfortran has this
> option, but with a twist related to the size of the local arrays (they
> recommend using -frecursive for parallel programs).
>
>> And also, the Intel thread checker threw up reports about potential data
>> races within deuler.f.
>
> Looks like that would only be true if some SAVEing is enabled. Wonder what
> the default in g95 is.
Compiling the following using g95 and no additional options, suggests
that locals are static:
program testf
call a( 1 )
call a( 2 )
end
subroutine a( i )
if( i .eq. 1 ) fred = 1.234
write(*,*) fred
end
In that fred retains it's value of 1.234 on the second call to "a".
David
> Peter.
>
--
Note my change of e-mail address. Please send e-mail to
[log in to unmask] from now on.
|