[Bug fortran/34438] New: gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[Bug fortran/34438] New: gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[sven dot buijssen at math dot uni-dortmund dot de]

gfortran 4.1.x, 4.2.x and 4.3.x are not compliant with the standard, section
4.4

'Unlike explicit initialization, default initialization does not imply that
the object has the SAVE attribute'

for the following testcase:


--- cut here ---
program main
  type myint
    integer :: bar = 0
  end type myint

  call recfunc(1)

contains

  recursive subroutine recfunc(ivalue)
    integer, intent(in) :: ivalue
    type(myint) :: foo

    foo%bar = ivalue
    if (ivalue .le. 3) then
      print *, "recursion level", ivalue, "value of local variable:", foo%bar
      call recfunc(ivalue + 1)
      print *, "recursion level", ivalue, "value of local variable:", foo%bar
    endif

  end subroutine recfunc

end program main
--- cut here ---

The default initialization of the component "bar" leads to "type(myint) ::
foo" having the SAVE attribute when compiled with gfortran. But "foo" should
only get the SAVE attribute if it were explicitly initialized. (The constraint
in 11.3 does not hold here)

$ gfortran -Wall demo.f90  && ./a.out
 recursion level           1 value of local variable:           1
 recursion level           2 value of local variable:           2
 recursion level           3 value of local variable:           3
 recursion level           3 value of local variable:           4
 recursion level           2 value of local variable:           4
 recursion level           1 value of local variable:           4

Recent version of PGI, Pathscale, Intel, SunStudio and G95 yield instead:
 recursion level 1 value of local variable: 1
 recursion level 2 value of local variable: 2
 recursion level 3 value of local variable: 3
 recursion level 3 value of local variable: 3
 recursion level 2 value of local variable: 2
 recursion level 1 value of local variable: 1

gfortran behaves like the other compilers when the default initialization of
component "bar" in the type definition is removed:

  [...]
  type myint
    integer :: bar
  end type myint
  [...]


Conversely, the compilers mentioned behave like gfortran if the variable "foo"
explicitly gets the SAVE attribute:

    [...]
    type(myint), save :: foo
    [...]


For sake of completeness:
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.x/configure --enable-shared
--enable-languages=c,c++,fortran --enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.3 20071211 (prerelease)

$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.x/configure --enable-shared
--enable-languages=c,c++,fortran --enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.2.3 20071211 (prerelease)

$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.x/configure --enable-shared
--enable-languages=c,c++,fortran --enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.3.0 20071211 (experimental) (GCC)


-- 
           Summary: gfortran not compliant w.r.t default initialization of
                    derived type component and implicit SAVE attribute
           Product: gcc
           Version: 4.2.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sven dot buijssen at math dot uni-dortmund dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2007-12-11 23:22 -------
Can you provide a standard conforming program that 
illustrates the problem (because your code violates
the standard)?


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |32834
              nThis|                            |
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-12 07:05:23
               date|                            |


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[sven dot buijssen at math dot uni-dortmund dot de]

------- Comment #2 from sven dot buijssen at math dot uni-dortmund dot de  2007-12-12 15:04 -------
Having reread the Fortran 95 language spec I don't see why the initial testcase
violates the standard. But I managed to distill a testcase that does not need
recursive functions and still triggers the bug of 'foo' getting implicitly the
SAVE attribute:

--- cut here ---
module demo
  implicit none
  private
  type myint
    integer :: bar = 42
  end type myint
  public :: func
contains
  subroutine func(ivalue)
    integer, intent(in) :: ivalue
    type(myint) :: foo
    print *, foo%bar
    foo%bar = ivalue
  end subroutine func
end module demo

program main
  use demo
  implicit none
  call func(1)
  call func(2)
end program main
--- cut here ---

In case this piece of code still violates the standard, I would very much
appreciate a hint where and why exactly it does. (Sorry to waste your time.)

gfortran 4.[1-2].x gives:
$ gfortran -W -Wall -pedantic -std=f95 demo3.f90 && ./a.out
          42
           1
while one would expect two times '42' as do Intel Fortran 9.x/10.x, PGI 7.x,
Pathscale 3.x, recent g95 versions, Compaq Fortran X5.4A-1684 and Sun Fortran
95 8.3 2007/07/18.

Without the private/public statements gfortran 4.3.x exhibits the same
behaviour. The test case above, however, gives

    type(myint) :: foo
                     1
Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type
'myint'

which seems unrelated to me and for which I probably should submit a new bug
report. I added this information here nonetheless as it might help to trace the
problem.


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[jv244 at cam dot ac dot uk]

------- Comment #3 from jv244 at cam dot ac dot uk  2007-12-12 16:11 -------
(In reply to comment #2)

I had confirmed the bug already on the first testcase, which is fine. 


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2007-12-12 20:29 -------
> Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type
> 'myint'
> which seems unrelated to me and for which I probably should submit a new bug
> report.

It is unrelated, but simple to fix; patch:
http://gcc.gnu.org/ml/fortran/2007-12/msg00153.html

(I think the first example is standard conform and should be enough, though I
am glad that you created the other example and found a diagnostics bug.)

Thanks for your two-in-one bugreport.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2007-12-14 12:53 -------
I can see a clean way to do this one - I shall be stuck in Frankfurt for three
hours tonight; I'll do it then.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-12-12 07:05:23         |2007-12-14 12:53:12
               date|                            |


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2007-12-14 15:14 -------
Subject: Bug 34438

Author: burnus
Date: Fri Dec 14 15:14:29 2007
New Revision: 130933

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130933
Log:
2007-12-14  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34438
        * resolve.c (resolve_symbol): Do not emit public-variable-
        of-private-derived-type error for non-module variables.

2007-12-14  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34438
        * gfortran.dg/private_type_10.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/private_type_10.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2007-12-15 00:29 -------
Created an attachment (id=14761)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14761&action=view)
A prototype patch

This is as far as I got at the airport - it fixes the problem but has not yet
been fully regtested.  'twill be done on Sunday.

Paul


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2007-12-17 20:03 -------
Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00219.html


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[pault at gcc dot gnu dot org]

------- Comment #9 from pault at gcc dot gnu dot org  2007-12-21 21:20 -------
Subject: Bug 34438

Author: pault
Date: Fri Dec 21 21:20:38 2007
New Revision: 131124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131124
Log:
2007-12-21  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34438
        * trans-decl.c (gfc_finish_var_decl): Do not mark derived types
        with default initializers as TREE_STATIC unless they are in the
        main program scope.
        (gfc_get_symbol_decl): Pass derived types with a default
        initializer to gfc_defer_symbol_init.
        (init_default_dt): Apply default initializer to a derived type.
        (init_intent_out_dt): Call init_default_dt.
        (gfc_trans_deferred_vars): Ditto.

        * module.c (read_module): Check sym->module is there before
        using it in a string comparison.

2007-12-21  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34438
        * gfortran.dg/default_initialization_3.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/default_initialization_3.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[tkoenig at gcc dot gnu dot org]

------- Comment #10 from tkoenig at gcc dot gnu dot org  2007-12-26 14:25 -------
This should be fixed on trunk.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[sven dot buijssen at math dot uni-dortmund dot de]

------- Comment #11 from sven dot buijssen at math dot uni-dortmund dot de  2007-12-26 22:00 -------
Can this patch be backported to 4.2?


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2007-12-26 23:42 -------
(In reply to comment #11)
> Can this patch be backported to 4.2?
> 

Is it a regression from an earlier version of gfortran?
If the answer to this question is 'No', then it is not
a candidate for a back port.


-- 


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

[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute

[sven dot buijssen at math dot uni-dortmund dot de]

------- Comment #13 from sven dot buijssen at math dot uni-dortmund dot de  2007-12-28 10:54 -------
(In reply to comment #12)
No, it is not a regression. All releases since 4.0.0 and the 4.[0-2] branches
are affected. I just asked because the only information I could find about the
current backport policy is the thread
http://gcc.gnu.org/ml/fortran/2006-10/msg00582.html.

My understanding of it, which might very well be wrong, is that bug 34438 -
being one that produces wrong code - could meet the backport criteria such that
we could see it fixed in an eventual 4.2.3.

Never mind, thank you guys very much for fixing it on the trunk.


-- 


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