[Patch, fortran] PR24158 - recursive derived types - part 1

Paul Thomas paulthomas2@wanadoo.fr
Sun Oct 9 12:21:00 GMT 2005


:ADDPATCH fortran:

Steve,

Thanks for picking up the bad patch for PR24092.  This was a consequence 
of developing the patches on my workstation, transferring the patches to 
my portbale and preparing the submit messages whilst away.  I had not 
copied the trans-types patch and redid it on the fly.  The funny thing 
is that it  tested OK.  I have decided to hold that bit back for a 
couple of days.  I have a cleaner algorithm in mind that does not leave 
unused field lists lying around.  Although there is not a problem with 
cleaning up, I think that it is much more hygenic to do it the new way.  
In the mean time, please find enclosed the patch for PR24158 and the 
associated testcases.
 
PR24158 concerns recursion, where the undefined component is a derived 
type, rather than a pointer.   gfortran makes a determined effort to 
build this structure, with the inevitable result!  The discussion on the 
list centred on the choice between detecting the recursion or, following 
the standard, only permitting  already defined derived type components.  
Since the consensus was that the standard should be adherred to, the 
patch does the latter by repairing the bit of broken code in decl.c 
(gfc_match_data_decl) that was meant to take care of this.  I have 
detected other circumstances in which an attempt is made to make use of 
an undefined derived type; typically these involve implicit typing and 
use association.  I have put a catch-all backstop(wicket keeper...) in 
resolve_symbol to produce an error in these cases.

Bubblestrapped and regtested under FC3/Athlon.  OK for mainline and 4.0?

Paul T

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: submit_nonpointer.txt
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20051009/4093d6cf/attachment.txt>


More information about the Fortran mailing list