[Bug fortran/40167] New: wrong initialization of local variable in a recursive subroutine

[Bug fortran/40167] New: wrong initialization of local variable in a recursive subroutine

[francois dot jacq at irsn dot fr]

In the following program, env%n should be equal to zero when entering the
routine "titi" but one gets the output :

  10 0
   5 10

instead of

  10 0
   5 0

as if the local variable "env" was declared "save" within "titi". Notice that
the bug disappears if the allocatable array "a" is deleted in the definition of
"env_type" : so the presence of an allocatable element within a derived type
seems to be related to that bug.

MODULE m

  TYPE env_type
    INTEGER :: n=0
    INTEGER,ALLOCATABLE :: a(:)
  END TYPE

  CONTAINS

  RECURSIVE SUBROUTINE titi(n)

    INTERFACE
      RECURSIVE SUBROUTINE tata()
      END SUBROUTINE
    END INTERFACE

    TYPE(env_type) :: env
    WRITE(*,*) n,env%n
    env%n=n
    IF(n == 5) STOP
    CALL tata()

  END SUBROUTINE

END MODULE

RECURSIVE SUBROUTINE tata
  USE m
  CALL titi(5)
END SUBROUTINE

PROGRAM test
  USE m
  INTERFACE
    RECURSIVE SUBROUTINE tata()
    END SUBROUTINE
  END INTERFACE
  CALL titi(10)
END PROGRAM


-- 
           Summary: wrong initialization of local variable in a recursive
                    subroutine
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: francois dot jacq at irsn dot fr
  GCC host triplet: windows xp i386
GCC target triplet: gcc 4.3.0 20080305 (alpha-testing) mingw-20080502


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167

[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2009-05-18 04:46 -------
(In reply to comment #0)
> In the following program, env%n should be equal to zero when entering the
> routine "titi" but one gets the output :
> 
>   10 0
>    5 10
> 
> instead of
> 
>   10 0
>    5 0

I get the correct output with:
GNU Fortran (GCC) 4.5.0 20090516 (experimental), 4.4.1 20090510 (prerelease)
 and  4.3.4 20090404 (prerelease)

This has evidently been fixed :-)

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167

[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-05-18 06:41 -------
I can reproduce the problem with GCC 4.2.1,
but it works with 4.3.3 [gcc-4_3-branch revision 144878]. Thus it seems to be
fixed in newer 4.3 versions than your 4.3.0 2008-03-05. And it works in 4.4.x
and 4.5. Please update to 4.3.4, 4.4.0 or 4.5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167

[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine

[francois dot jacq at irsn dot fr]

------- Comment #3 from francois dot jacq at irsn dot fr  2009-05-18 07:43 -------
OK but I just downloaded the last binary package proposed by the website
http://www.mingw.org

Were could I find a more recent binary Mingw package for gfortran ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167

[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine

[francois dot jacq at irsn dot fr]

------- Comment #4 from francois dot jacq at irsn dot fr  2009-05-18 08:17 -------
I answer to my question :

a more recent binary package is proposed by
http://gcc.gnu.org/wiki/GFortranBinaries (4.5.0 20090421)

Sorry for this useless bug report

regards

FJ


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167

[Bug fortran/40167] wrong initialization of local variable in a recursive subroutine

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-05-18 08:51 -------
(In reply to comment #4)
> Sorry for this useless bug report

Well, the quality of gfortran relies on bug reports. As long as the
signal-to-noise ratio does not fall too much, it is better to have one bug
invalid bug than missing a real bug.

Close it as WONTFIX.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40167