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)
Can you provide a standard conforming program that illustrates the problem (because your code violates the standard)?
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.
(In reply to comment #2) I had confirmed the bug already on the first testcase, which is fine.
> 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.
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
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
Created attachment 14761 [details] 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
Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00219.html
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
This should be fixed on trunk. Closing.
Can this patch be backported to 4.2?
(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.
(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.