gfortran segfaults while compiling an f90 source file that uses modules.
Created attachment 6872 [details] f90 source file. gfortran segfaults when comoiling this source This is the source file that casues the compiler to segfault
gfortran -v output is: Configured with: ../gcc/configure --prefix=/people/comp/compiler/gcc --enable-version-specific-runtime-libs --with-gcc-version-trigger=/people/comp/tmp/gcc/gcc/version.c --enable-languages=c,c++,f95 Thread model: posix gcc version 3.5.0 20040802 (experimental) gfortran -c NullInterp_Interp.f90 gives: NullInterp_Interp.f90:25: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
I compiled gcc and the included source file on a dual xeon 2.4G computer running RedHat 9.0
Confirmed. Here's a shorter testcase: ===================================== module FOO integer :: I end module FOO module BAR contains subroutine BAZ(J) use FOO integer, dimension(I) :: J end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS =====================================
And here is the backtrace (mainly for finding dups easier): Program received signal SIGSEGV, Segmentation fault. 0x0807bf03 in gfc_resolve_expr (e=0x85bd750) at /home/gates/pinskia/src/gnu/gcc/src/gcc/ fortran/resolve.c:1973 1973 sym = e->symtree->n.sym; (gdb) bt #0 0x0807bf03 in gfc_resolve_expr (e=0x85bd750) at /home/gates/pinskia/src/gnu/gcc/src/gcc/ fortran/resolve.c:1973 #1 0x0804f891 in resolve_array_bound (e=0x85bd750, check_constant=0) at /home/gates/pinskia/ src/gnu/gcc/src/gcc/fortran/array.c:220 #2 0x0804f94b in gfc_resolve_array_spec (as=0x85bd6a8, check_constant=0) at /home/gates/ pinskia/src/gnu/gcc/src/gcc/fortran/array.c:254 #3 0x0807b3b1 in resolve_formal_arglist (proc=0x85bcf70) at /home/gates/pinskia/src/gnu/gcc/src/ gcc/fortran/resolve.c:131 #4 0x0807b79d in find_arglists (sym=0x85bcf70) at /home/gates/pinskia/src/gnu/gcc/src/gcc/ fortran/resolve.c:232 #5 0x0808b4c9 in traverse_ns (st=0x85bcf18, func=0x807b770 <find_arglists>) at /home/gates/ pinskia/src/gnu/gcc/src/gcc/fortran/symbol.c:2318 #6 0x0808b507 in gfc_traverse_ns (ns=0x85b1490, func=0x807b770 <find_arglists>) at /home/ gates/pinskia/src/gnu/gcc/src/gcc/fortran/symbol.c:2335 #7 0x0807fe4f in gfc_resolve (ns=0x85b1490) at /home/gates/pinskia/src/gnu/gcc/src/gcc/fortran/ resolve.c:246 #8 0x08078337 in gfc_parse_file () at /home/gates/pinskia/src/gnu/gcc/src/gcc/fortran/parse.c: 2616 #9 0x0808da7a in gfc_be_parse_file (set_yydebug=0) at /home/gates/pinskia/src/gnu/gcc/src/gcc/ fortran/f95-lang.c:266 #10 0x08387fde in toplev_main (argc=0, argv=0xbffec2d4) at /home/gates/pinskia/src/gnu/gcc/src/ gcc/toplev.c:981 #11 0x420174d9 in __libc_start_main () from /lib/i686/libc.so.6 #12 0x0804b011 in _start ()
Ditto on powerpc-unknown-linux-gnu, using gcc-3.5-20040907.
*** Bug 17588 has been marked as a duplicate of this bug. ***
*** Bug 17764 has been marked as a duplicate of this bug. ***
The bug 17764 was incorrectly linked to this (see comments in that entry). I simplified the 20k source file above to ~600 bytes. Compilation attempt (using gfortran as of Nov 09, 2004) still gives "Internal compiler error. Segmentation fault." Now, the simplified code is: --- snip --- module NullGrid_Vars implicit none ! INTEGER*4, parameter :: lsh = 10 INTEGER*4, save :: lsh end module NullGrid_Vars ! module NullInterp_InterpUtil implicit none contains subroutine NullInterp_Util_cinterp(J1) use NullGrid_Vars implicit none !input variables COMPLEX*16, dimension(lsh), intent(inout) :: J1 end subroutine NullInterp_Util_cinterp end module NullInterp_InterpUtil ! module NullInterp_Interp implicit none contains subroutine NullInterp_cinterp() use NullGrid_Vars use NullInterp_InterpUtil implicit none end subroutine NullInterp_cinterp end module NullInterp_Interp --- snip --- As you may see, the second module (NullInterp_InterpUtil) gives the dimension of its in/out array as the variable lsh from the first module (NullGrid_Vars). However, lsh is a variable (although SAVEd). I'm not a standard guru, but it seems to me that such behavior is wrong, as the array size cannot be known at compilation time. If lsh is made a parameter (uncomment the line, comment the save line), then the code compiles without a hitch. Summary: I believe this is a bug in Fortran source file submitted as a test case, and not a gfortran bug. The 17764 was a genuine gfortran bug, and it was corrected during the last couple days (I checked couple times a week, so cannot pinpoint the exact moment).
The 11th November still gives this behaviour. However, if the USE FOO is raised to the module level, all is well. For example, this slightly expanded version compiles and runs fine. module FOO integer :: I=2 end module FOO module BAR use FOO contains subroutine BAZ(J) integer, dimension(I) :: J print * ,"BAZ: size(j) =", size(J) end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS program test_mod use FOO USE BAR integer, dimension(I) :: j I=3 call BAZ(j) call QUUS(2) print * ,"MAIN: size(j) =", size(J) end program test_mod (In reply to comment #4) > Confirmed. Here's a shorter testcase: > ===================================== > module FOO > integer :: I > end module FOO > module BAR > contains > subroutine BAZ(J) > use FOO > integer, dimension(I) :: J > end subroutine BAZ > end module BAR > subroutine QUUS() > use FOO > use BAR > end subroutine QUUS > =====================================
*** Bug 19460 has been marked as a duplicate of this bug. ***
I confirm this issue is still present as of 2005-01-18. As a important number of people here, this is blocking my code from compiling smoothly.
I think I found a patch for this one. See http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html
Hi, The patch seems to fix part of the problem (the simplified test code from comment 4 now compiles), but the original code that I submitted still causes gfortran to segfault. I simplified my original code to the following test code that also causes gfortran (with the patch) to segfault. module MOD1 implicit none INTEGER, dimension(2) :: lsh end module MOD1 module MOD2 implicit none contains subroutine SUB1(J1) use MOD1 implicit none !input variables COMPLEX, dimension(lsh(1),lsh(2)), intent(inout) :: J1 end subroutine SUB1 end module MOD2 module MOD3 use MOD1 use MOD2 end module MOD3
Subject: Bug 16861 CVSROOT: /cvs/gcc Module name: gcc Changes by: fxcoudert@gcc.gnu.org 2005-04-19 07:10:06 Modified files: gcc/fortran : ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr16861.f90 Log message: PR fortran/16861 * resolve.c (resolve_variable): If e->symtree is not set, this ought to be a FAILURE, and not a segfault. * gfortran.dg/pr16861.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.397&r2=1.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.39&r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5369&r2=1.5370 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Like comment #5 says, this one is not fixed. The patch I committed only adress part of the issue. Removed patch keyword accordingly.
Subject: Bug 16861 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: fxcoudert@gcc.gnu.org 2005-04-29 10:56:18 Modified files: gcc/fortran : ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr16861.f90 Log message: PR fortran/16861 * resolve.c (resolve_variable): If e->symtree is not set, this ought to be a FAILURE, and not a segfault. * gfortran.dg/pr16861.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.42&r2=1.335.2.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.6&r2=1.34.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.148&r2=1.5084.2.149 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.4.1
For the example in comment #14, the USE of MOD2 in MOD3 is not parsing the saved MOD2 module correctly causing J1 to be restored with a NULL symtree.
Created attachment 9282 [details] write contained namespaces The problem appears to be that gfortran module output does not iterate over contained namespaces and only writes the parent namespace. This patch is a start at a solution. I do not know if omitting MODULE symbols is sufficient to avoid other problems. The change does write some symtrees multiple times, which is not necessarily an error, but is inefficient.
Created attachment 9283 [details] write contained namespaces walk namespaces recursively
Created attachment 9284 [details] write symbols and symtrees in contained namespaces recursively walk namespaces for symbols in addition to symtrees.
Created attachment 9286 [details] symbols in contained namespaces With the earlier parts of the patch emitting more symbols, we need to avoid marking a symbol as ambiguous unnecessarily.
Created attachment 9553 [details] failing testcase for labels $ ifort -W1 -check all -o do.o -c do.f90 ;echo $? 0 $ gfortran-4.1-HEAD -o do.o -c do.f90 In file do.f90:15 end module 1 Internal Error at (1): write_symbol(): bad module symbol 'converg'
Created attachment 9554 [details] failing testcase for double use mod $ gfortran-4.1-HEAD -o bugger.o -c bugger.f90 bugger.f90: In function 'sub2': bugger.f90:19: internal compiler error: in gfc_finish_var_decl, at fortran/trans-decl.c:436 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. It does, however appear to cure PR 19669: $ gfortran-4.1-HEAD -o _pr19669.o -c pr19669.f90 -v ;echo $? Using built-in specs. Target: i686-linux-gnu Configured with: ../../src/gcc/configure -v --enable-languages=c,c++,f95,treelang --prefix=/opt/gcc-4.1/ --enable-shared --with-system-zlib --libexecdir=/opt/gcc-4.1/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.1-HEAD --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=release --enable-debug i686-linux-gnu Thread model: posix gcc version 4.1.0 20050822 (experimental) /opt/gcc-4.1/bin/../../gcc-4.1/lib/gcc/i686-linux-gnu/4.1.0/f951 pr19669.f90 -quiet -dumpbase pr19669.f90 -mtune=pentiumpro -auxbase-strip _pr19669.o -version -o /tmp/ccAz85Hh.s GNU F95 version 4.1.0 20050822 (experimental) (i686-linux-gnu) compiled by GNU C version 4.0.1 (Debian 4.0.1-2). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96982 as -V -Qy -o _pr19669.o /tmp/ccAz85Hh.s GNU assembler version 2.16.1 (i486-linux-gnu) using BFD version 2.16.1 Debian GNU/Linux 0
(In reply to comment #22) A thoroughly reduced testcase is: module foo INTEGER :: i end module foo module bar contains subroutine sub(j) use foo integer, dimension(i) :: j !change dimension to explicit clears bug end subroutine sub end module bar module foobar use foo !or eliminate this to clear bug use bar end module foobar The ICE occurs whilst writing foobar because the symtree for the arrayspec for j has no symbol for i, as said in the discussion in the PR. This has the effect of causing the ICE here: static void mio_symtree_ref (gfc_symtree ** stp) { pointer_info *p; fixup_t *f; if (iomode == IO_OUTPUT) { mio_symbol_ref (&(*stp)->n.sym); <<<<<right here If one passes mio_symbol_ref, when there is no symbol, the above compiles. However, the module is not viable because it lacks the integer pointing to i in j's arrayspec. Two suggestive bits of information are: (i) Interchanging the order of the two final USE statements allows the module to compile successfully to the extent that it can be USED viably. This I assume would be a viable workaround for the code concerned. I checked that reversing the order of USE NullInterp_InterpUtil and USE NullGrid_Vars everywhere in the first example to the PR produced good code. (ii) Changing foobar to a program or subroutine gives successful compilations for either order of the USE statements. Again, viable code is produced. (This is why I thought that the bug had been cured!) There must be some crucial difference in the treatment of modules but I have not yet identified it. I am working my way through the code preceding gfc_dump_module but have to stop right now. Will pick up again in the morning. I need to study your contributions, David, to find out what exactly they were doing. I apologise if I seemed a bit dismissive but I really thought that the problem was solved; as I now understand, due to (ii) above. Paul
I did not want to mess around by submitting from a Windows machine again, so here is a preview of a proposed patch: ============================================================================== This proposed patch is a fix for PR16861, in which module procedures with assumed shape dummy arguments would cause ICEs, when the indices themselves were use associated. The patch works by recognising that symbols from different namespaces, within a module, should have different true_name entries. This permits the correct resolution of references, when building the array_specs for the assumed shape arrays. The backend referencing comes right because there is only one symtree entry for each variable name, regardless of how many true_name entries there might be. The cost for this simple patch is slight: Each symbol is represented in the .mod file so that, in the testcase below, the symbol i appears three times in foobar.mod; once for each namespace. foobar.mod will be found after the testcase. Evidently, it is not necessary to store this information in the module files, since g95 does not. I rather like this explicit approach. However, it could be fixed later by a bit of hacking in the code called by write_symbol[x], such that only the index in the module namespace is stored and that the references be redirected to this. In the course of diagnosing the problem and developing the testcase, I noticed that the FIXME on lines 3487-3497 had fixed itself and that the chunk of added code is now redundant. I therefore took the opportunity to remove it. If anbody recalls what triggered the condition, I would be grateful if they would let me know. Regtesting does not reveal the need for this. Regtested on Cygwin/i686 and FC3/Athlon 1700. OK for mainline and 4.03, when open? Paul T =================================================================== 2005-09-15 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * module.c (read_module): Give symbols from module procedures different true_name entries to those from the module proper. 2005-09-15 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * gfortran.dg/nested_modules_2.f90: New test. Index: gcc/gcc/fortran/module.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/fortran/module.c,v retrieving revision 1.36 diff -c -p -r1.36 module.c *** gcc/gcc/fortran/module.c 9 Sep 2005 00:23:06 -0000 1.36 --- gcc/gcc/fortran/module.c 15 Sep 2005 12:42:44 -0000 *************** read_module (void) *** 3101,3107 **** const char *p; char name[GFC_MAX_SYMBOL_LEN + 1]; gfc_intrinsic_op i; ! int ambiguous, symbol, j, nuse; pointer_info *info; gfc_use_rename *u; gfc_symtree *st; --- 3101,3107 ---- const char *p; char name[GFC_MAX_SYMBOL_LEN + 1]; gfc_intrinsic_op i; ! int ambiguous, symbol, j, nuse, series; pointer_info *info; gfc_use_rename *u; gfc_symtree *st; *************** read_module (void) *** 3122,3127 **** --- 3122,3128 ---- /* Create the fixup nodes for all the symbols. */ + series = 0; while (peek_atom () != ATOM_RPAREN) { require_atom (ATOM_INTEGER); *************** read_module (void) *** 3144,3149 **** --- 3145,3158 ---- being loaded again. */ sym = find_true_name (info->u.rsym.true_name, info->u.rsym.module); + + /* If a module contains subroutines with assumed shape dummy + arguments, the symbols for indices need to be different from + from those in the module proper(ns = 1). */ + if (sym !=NULL && info->u.rsym.ns !=1) + sym = find_true_name (info->u.rsym.true_name, + gfc_get_string ("%s@%d",module_name, series++)); + if (sym == NULL) continue; *************** write_symbol1 (pointer_info * p) *** 3487,3497 **** if (p->type != P_SYMBOL || p->u.wsym.state != NEEDS_WRITE) return 0; - /* FIXME: This shouldn't be necessary, but it works around - deficiencies in the module loader or/and symbol handling. */ - if (p->u.wsym.sym->module == NULL && p->u.wsym.sym->attr.dummy) - p->u.wsym.sym->module = gfc_get_string (module_name); - p->u.wsym.state = WRITTEN; write_symbol (p->integer, p->u.wsym.sym); --- 3496,3501 ---- *************** write_module (void) *** 3610,3615 **** --- 3614,3620 ---- mio_lparen (); write_symbol0 (gfc_current_ns->sym_root); + while (write_symbol1 (pi_root)); mio_rparen (); =======================nested_modules_2.f90================== ! { dg do-run } ! This tests the patch for PR16861. ! ! Contributed by Paul Thomas <pault@gcc.gnu.org> ! module foo INTEGER :: i end module foo module bar contains subroutine sub1 (j) use foo integer, dimension(i) :: j j = 42 end subroutine sub1 subroutine sub2 (k) use foo integer, dimension(i) :: k k = 84 end subroutine sub2 end module bar module foobar use foo !This used to cause an ICE use bar end module foobar program testfoobar use foobar integer, dimension(3) :: l = 0 i = 2 call sub1 (l) i = 1 call sub2 (l) if (all (l.ne.(/84,42,0/))) call abort () end program testfoobar =======================foobar.mod====================== Note: 1) The symtree i points to symbol 11, which is in namespace 1; ie. the module namespace. 2) The lower index of j points to symbol 12, which is in namespace 6; ie. that of j and sub1. 3) Similarly the index of k points to symbol 13, which is in namespace 9, being that of k and sub2. $ cat foobar.mod GFORTRAN module created from pr16861.f90 on Thu Sep 15 15:21:05 2005 If you edit this, you'll get what you deserve. (() () () () () () () () () () () () () () () () () () () ()) () () () () (2 'bar' 'bar' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 () ()) 3 'foobar' 'foobar' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) ( UNKNOWN 0 ()) 0 0 () () 0 () ()) 4 'foo' 'foo' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 () ()) 5 'sub1' 'bar' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL SUBROUTINE) (UNKNOWN 0 ()) 6 0 (7) () 0 () ()) 8 'sub2' 'bar' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL SUBROUTINE) (UNKNOWN 0 ()) 9 0 (10) () 0 () ()) 11 'i' 'foo' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (INTEGER 4 ()) 0 0 () () 0 () ()) 7 'j' '' 6 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) (INTEGER 4 ()) 0 0 () (1 EXPLICIT (CONSTANT (INTEGER 4 ()) 0 '1') (VARIABLE (INTEGER 4 ()) 0 12 ())) 0 () ()) 10 'k' '' 9 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN DIMENSION DUMMY) (INTEGER 4 ()) 0 0 () (1 EXPLICIT (CONSTANT (INTEGER 4 ()) 0 '1') (VARIABLE (INTEGER 4 ()) 0 13 ())) 0 () ()) 13 'i' 'foo' 9 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (INTEGER 4 ()) 0 0 () () 0 () ()) 12 'i' 'foo' 6 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (INTEGER 4 ()) 0 0 () () 0 () ()) ) ('i' 0 11 'foo' 0 4 'bar' 0 2 'foobar' 0 3 'sub2' 0 8 'sub1' 0 5)
Subject: Bug 16861 CVSROOT: /cvs/gcc Module name: gcc Changes by: pault@gcc.gnu.org 2005-09-18 05:18:55 Modified files: gcc/fortran : module.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: nested_modules_2.f90 Log message: 2005-09-18 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * module.c (read_module): Give symbols from module procedures different true_name entries to those from the module proper. 2005-09-18 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * gfortran.dg/nested_modules_2.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.557&r2=1.558 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6074&r2=1.6075
All of these are fixed in 4.1.0. Since 4.0.2 is the last 4.0 release before a 4.1.0 release will be made, 4.0.2 and 4.0.1 were special releases for gfrotran. 4.0.3 should be a normal release for GCC and gfortran in that regressions are the only changes.
Subject: Bug 16861 CVSROOT: /cvs/gcc Module name: gcc Changes by: pault@gcc.gnu.org 2005-09-23 17:16:07 Modified files: gcc/fortran : module.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: nested_modules_3.f90 Log message: 2005-09-23 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * module.c (mio_component_ref): Return if the symbol is NULL and wait for another iteration during module reads. (mio_symtree_ref): Suppress the writing of contained symbols, when a symbol is available in the main namespace. (read_module): Restrict scope of special treatment of contained symbols to variables only and suppress redundant call to find_true_name. 2005-09-23 Paul Thomas <pault@gcc.gnu.org> PR fortran/16861 * gfortran.dg/nested_modules_3.f90: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&r1=1.39&r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.567&r2=1.568 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6100&r2=1.6101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 16861 Author: pault Date: Fri Nov 11 05:37:40 2005 New Revision: 106779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106779 Log: 2005-11-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/24655 PR fortran/24755 * match.c (recursive_stmt_fcn): Add checks that symtree exists for the expression to weed out inline intrinsic functions and parameters. PR fortran/24409 PR fortran/16861 * module.c (mio_component_ref): Return if the symbol is NULL and wait for another iteration during module reads. (mio_symtree_ref): Suppress the writing of contained symbols, when a symbol is available in the main namespace. Take care that a symbol is not substituted for by a the symbol for the module itself and prevent the promotion of a formal argument. (read_module): Give symbols for variables from contained module procedures different true_name entries to those from the module proper. 2005-11-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/24655 PR fortran/24755 * gfortran.dg/recursive_statement_functions.f90: Add statement functions using inline intrinsic functions and parameters to test that they no longer seg-fault. PR fortran/24409 * gfortran.dg/nested_modules_4.f90: New test. * gfortran.dg/nested_modules_5.f90: New test. PR fortran/16861 * gfortran.dg/nested_modules_3.f90: New test. * gfortran.dg/nested_modules_2.f90: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/nested_modules_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/nested_modules_3.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/nested_modules_4.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/nested_modules_5.f90 Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/match.c branches/gcc-4_0-branch/gcc/fortran/module.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/nested_modules_1.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/recursive_statement_functions.f90
For some reason, this never got fixed on 4.0. It is now!