[Bug fortran/16861] New: gfortran compiler segfault

[Bug fortran/16861] New: gfortran compiler segfault

[yosef at phys dot utb dot edu]

gfortran segfaults while compiling an f90 source file that uses modules.

-- 
           Summary: gfortran compiler segfault
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: yosef at phys dot utb dot edu
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug fortran/16861] gfortran compiler segfault

[yosef at phys dot utb dot edu]

------- Additional Comments From yosef at phys dot utb dot edu  2004-08-03 17:28 -------
Created an attachment (id=6872)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6872&action=view)
f90 source file. gfortran segfaults when comoiling this source

This is the source file that casues the compiler to segfault

-- 


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

[Bug fortran/16861] gfortran compiler segfault

[yosef at phys dot utb dot edu]

------- Additional Comments From yosef at phys dot utb dot edu  2004-08-03 17:31 -------
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.


-- 


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

[Bug fortran/16861] gfortran compiler segfault

[yosef at phys dot utb dot edu]

------- Additional Comments From yosef at phys dot utb dot edu  2004-08-03 17:34 -------
I compiled gcc and the included source file on a dual
xeon 2.4G computer running RedHat 9.0

-- 


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

[Bug fortran/16861] gfortran compiler segfault

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-08-03 18:12 -------
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
=====================================


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-03 18:12:32
               date|                            |


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

[Bug fortran/16861] gfortran compiler segfault

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-03 21:20 -------
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 ()

-- 


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

[Bug fortran/16861] gfortran compiler segfault

[toon at moene dot indiv dot nluug dot nl]

------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2004-09-08 19:14 -------
Ditto on powerpc-unknown-linux-gnu, using gcc-3.5-20040907.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|i686-pc-linux               |


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

[Bug fortran/16861] gfortran compiler segfault

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-09-27 15:48 -------
*** Bug 17588 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |c dot lemmen at fz-juelich
                   |                            |dot de


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

[Bug fortran/16861] segfault with doubly used module

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-01 03:23 -------
*** Bug 17764 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitrym at acres dot com dot
                   |                            |au


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

[Bug fortran/16861] segfault with doubly used module

[dmitrym at acres dot com dot au]

------- Additional Comments From dmitrym at acres dot com dot au  2004-11-09 05:35 -------
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).

-- 


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

[Bug fortran/16861] segfault with doubly used module

[paul dot richard dot thomas at cea dot fr]

------- Additional Comments From paul dot richard dot thomas at cea dot fr  2004-12-02 10:38 -------
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
> =====================================



-- 


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

[Bug fortran/16861] segfault with doubly used module

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-15 17:13 -------
*** Bug 19460 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cummings at cacr dot caltech
                   |                            |dot edu


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

[Bug fortran/16861] segfault with doubly used module

[coudert at clipper dot ens dot fr]

------- Additional Comments From coudert at clipper dot ens dot fr  2005-01-18 13:10 -------
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.

-- 


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

[Bug fortran/16861] segfault with doubly used module

[fxcoudert at gcc dot gnu dot org]

------- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-18 13:12 -------
I think I found a patch for this one. See
http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|coudert at clipper dot ens  |fxcoudert at gcc dot gnu dot
                   |dot fr                      |org
  GCC build triplet|i686-pc-linux               |
 GCC target triplet|i686-pc-linux               |
           Keywords|                            |patch
   Last reconfirmed|2005-02-26 18:42:24         |2005-04-18 13:12:03
               date|                            |


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

[Bug fortran/16861] segfault with doubly used module

[yosef at phys dot utb dot edu]

------- Additional Comments From yosef at phys dot utb dot edu  2005-04-19 01:09 -------
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

-- 


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

[Bug fortran/16861] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 07:10 -------
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



-- 


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

[Bug fortran/16861] segfault with doubly used module

[fxcoudert at gcc dot gnu dot org]

------- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 07:24 -------
Like comment #5 says, this one is not fixed. The patch I committed only adress
part of the issue. Removed patch keyword accordingly.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |
   Last reconfirmed|2005-04-18 13:12:03         |2005-04-19 07:24:32
               date|                            |


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

[Bug fortran/16861] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 10:56 -------
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



-- 


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

[Bug fortran/16861] segfault with doubly used module

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2005-07-14 17:12 -------
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.

-- 


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

[Bug fortran/16861] segfault with doubly used module

[pault at gcc dot gnu dot org]

------- Additional Comments From pault at gcc dot gnu dot org  2005-09-11 16:28 -------
(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

-- 


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

[Bug fortran/16861] segfault with doubly used module

[paul dot richard dot thomas at cea dot fr]

------- Additional Comments From paul dot richard dot thomas at cea dot fr  2005-09-15 14:25 -------
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)



-- 


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

[Bug fortran/16861] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-18 05:19 -------
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



-- 


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

[Bug fortran/16861] [4.0 only] segfault with doubly used module

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|segfault with doubly used   |[4.0 only] segfault with
                   |module                      |doubly used module
   Target Milestone|---                         |4.0.2


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

[Bug fortran/16861] [4.0 only] segfault with doubly used module

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


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

[Bug fortran/16861] [4.0 only] segfault with doubly used module

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-18 20:26 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.0.3                       |4.1.0


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

[Bug fortran/16861] [4.0 only] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-23 17:16 -------
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



-- 


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