------- 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: [EMAIL PROTECTED] 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