[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