------- 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
