This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Interaction of -finit-local-zero and -fno-automatic
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Andrew Senior <a dot senior at lancaster dot ac dot uk>
- Cc: fortran at gcc dot gnu dot org
- Date: Thu, 29 Oct 2009 00:41:48 +0200
- Subject: Re: Interaction of -finit-local-zero and -fno-automatic
- References: <4AE5D48C.4040704@lancaster.ac.uk>
On Mon, Oct 26, 2009 at 18:55, Andrew Senior <a.senior@lancaster.ac.uk> wrote:
> Consider the following program:
>
> ? ? ?program test
>
> ? ? ?call mysub(1.)
> ? ? ?call mysub(2.)
>
> ? ? ?end
>
> ? ? ?subroutine mysub(x)
>
> c ? ? ?save y
>
> ? ? ?print *,"y=",y
> ? ? ?y=x
> ? ? ?print *,"y=",y
> ? ? ?end
>
> If I compile this with gfortran using both the -finit-local-zero and
> -fno-automatic flags, running the program produces:
>
> ?y= ? 0.0000000
> ?y= ? 1.0000000
> ?y= ? 0.0000000
> ?y= ? 2.0000000
>
> If I uncomment the 'save y' statement and recompile, running produces:
>
> ?y= ? 0.0000000
> ?y= ? 1.0000000
> ?y= ? 1.0000000
> ?y= ? 2.0000000
>
> If I leave 'save y' commented out, but recompile using only the
> -fno-automatic flag, the program does this:
>
> ?y= ? 0.0000000
> ?y= ? 1.0000000
> ?y= ? 1.0000000
> ?y= ? 2.0000000
>
> Based on past experience using g77, which has the same two flags as
> gfortran, I'd expect the first run above to produce the same result as the
> second one. With gfortran, it seems as if making a local variable static
> with -fno-automatic doesn't prevent it being re-initialised to zero by
> -finit-local-zero when the subroutine is called. However, making it static
> with 'save' does prevent this re-initialisation.
Yes, this doesn't make sense. This is now bug 41860
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
> It also seems as if
> -fno-automatic on its own initialises the variable to zero at the start of
> the program.
Yes, static data has to be stored somewhere in the object file, so
even if it is uninitialized we choose some value. 0 is nice because
then it matches C, and goes into the bss section instead of data.
> (If I compile and run the code above with no flags, the first
> value of y printed out is random).
Yes, because in that case y will have whatever junk was left on the
stack from some previous usage.
> I know that the correct solution is to avoid these flags entirely by writing
> code which doesn't make assumptions about local variables being static or
> being initialised to zero.
Bingo.
--
Janne Blomqvist