Recursive derived type specifications - PR21458 - a standard question.

[Paul Thomas]

This

module snafu
  type       ::   a
    type(b)    :: i
  end type a
  type       ::   b
    type(a)    :: i
  end type b
  type (a), pointer   :: foo
end module snafu

does this with gfortran:

[prt@localhost mytests]# /gcc-4.1/bin/gfortran -c snafu_1.f90
gfortran: Internal error: Segmentation fault (program f951)

I have developed a patch to resolve.c that detects the recursion and 
generates an error.  I have attached it, although I am not submitting it 
yet because of the question below. The patch allows through loops, where 
a pointer component is involved.

However, ifort does this:

fortcom: Error: snafu_1.f90, line 3: This derived type name has not been 
declared.   [B]
    type(b)    :: i
---------^
compilation aborted for snafu_1.f90 (code 1)

If the component of type(b) is made an integer the same error occurs in 
ifort but gfortran compiles the module successfully.

ifort, therefore, is requiring that the derived type specifications be 
in order; presumably to break recursion.  I cannot find anything in the 
standard that requires this and would claim that my patch is more 
standard compliant than ifort's ordering of specifications. In general, 
specification statements are not required to be in any particular order 
(eg. integer a; equivalence (a,b); integer b;), so this version of 
derived type definition seems more consistent.

However, if I am wrong, there is no big deal in implementing ifort's 
solution!

Does anybody know any better?

Paul T



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: check.diff
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20051001/fc3ef943/attachment.ksh>