[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code

["paulthomas2 at wanadoo dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #12 from paulthomas2 at wanadoo dot fr  2006-08-26 09:30 -------
Subject: Re:  [gfortran: 4.1, 4.2 regression] ICE on valid
 code

Jerry and Martin,

All of this is very depressing - I can reproduce the 32 bit version of 
the problem and, I suppose, will reproduce the 64 bit version in a 
moment.  There are three things that really start me scratching my head:

(i) gcc-4.2 has it that there is a format error in the module file itself:
[prt@localhost f90bug]# /svn-4.2/bin/gfortran -I./*.mod -c lensing.f90
Fatal Error: Reading module modelparams at line 27 column 73: Expected 
integer;
(ii) This difficulty disappears if I use 4.1; and
(iii) I cannot for the life of me understand what the -I. would do to 
affect the parsing and processing of the .mod file. (Jerry, is there any 
recent IO library modification that would do this?)

Still worse and what has me completely floored is this....

module z
  type :: x
    integer :: i
  end type x
end module z

module modeldata
  use z
  type :: cltransferdata
    type(x) :: ls
    integer :: numsources
    integer :: num_q_int
    real(8) :: q_int
    real(8) :: dq_int
    real(8) :: delta_p_l_k
  end type cltransferdata
end module modeldata

Produces a modeldata.mod like this:

GFORTRAN module created from tests.f90 on Sat Aug 26 10:43:24 2006
If you edit this, you'll get what you deserve.

(() () () ()
() () () () () () () () () () () () () () () () ())

()

()

()

()

(2 'cltransferdata' 'modeldata' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 ((3 'ls' (DERIVED 4 ()) () 0 0 0 ())
(5 'numsources' (INTEGER 4 ()) () 0 0 0 ()) (6 'num_q_int' (INTEGER 4 ())
() 0 0 0 ()) (7 'q_int' (REAL 8 ()) () 0 0 0 ()) (8 'dq_int' (REAL 8 ())
() 0 0 0 ()) (9 'delta_p_l_k' (REAL 8 ()) () 0 0 0 ())) PUBLIC ())
4 'x' 'z' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 ((10 'i' (INTEGER 4 ()) () 0 0 0 ())) PUBLIC ())
11 'z' 'z' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 () ())
12 'modeldata' 'modeldata' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 () ())
)

('modeldata' 0 12 'cltransferdata' 0 2 'z' 0 11 'x' 0 4)

Note the entry starting with (2 'cltransferdata'... ; this has a 
reference to the component 'ls' on the next line. (3 'ls' (DERIVED 4 ()) 
says that 'ls' is derived and is of a type that is defined in entry 4.  
This entry is:

4 'x' 'z' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN) (UNKNOWN 0 ())
0 0 () () 0 ((10 'i' (INTEGER 4 ()) () 0 0 0 ())) PUBLIC ())

which says that it is declared in module z, is derived and has an 
integer component i.

with the -I. option, like you, I get

  use ModelData
              1
Error: The component 'ls' is a PRIVATE type and cannot be a component of 
'cltransferdata', which is PUBLIC at (1)

(Why is it this USE statement and not others, either before or after?)

Anyway, ignoring this last question for the time being...., I find in 
modeldata.mod the entry(line 55)

24 'cltransferdata' 'modeldata' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN) (UNKNOWN 0 ()) 0 0 () () 0 ((25 'ls' (DERIVED 26 ()) () 0 0 ())
(27 'numsources' (INTEGER 4 ()) () 0 0 ()) (28 'num_q_int' (INTEGER 4 ())
() 0 0 ()) (29 'q_int' (REAL 8 ()) (1 DEFERRED () ()) 1 1 ()) (30 'dq_int'
(REAL 8 ()) (1 DEFERRED () ()) 1 1 ()) (31 'delta_p_l_k' (REAL 8 ()) (3
DEFERRED () () () () () ()) 1 1 ())) PUBLIC ())

You will see that 'ls' is of derived type declared in entry 26, which is 
present in the file but out of order.  That said, it does not matter 
where I put it, nor is it PRIVATE.

PRIVATE objects do not appear at all in .mod files.

I will think some more about this but I will, at the same time, prepare 
the patch to revert to the original state, with the kludged up version, 
in resolve.c, of the fixes for the PRs.  The release of 4.2.0 is 
looming!  This is such a pity because the current version of derived 
type association is so much better in principle.

Paul


-- 


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