[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