This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Status of allocatable components
On Mon, Jun 26, 2006 at 11:03:00PM +0200, Paul Thomas wrote:
> Erik,
>
> Thanks for posting this. It indicates how nearly we are there. I will
> just add a few comments below:
>
> >* The "automatic deallocation&allocation if necessary" on assignments
> > is the main thing left to be done.
> >
> >
> Are you working on this? If so, that would be great because....
Not yet, but I will start soon (like, about, tomorrow, for exemple).
> >* I have probably forgotten something.
> >
> >
> ... I thought to provide the modifications that are needed to the
> derived type constructor.
So I was right; I _did_ forget about something ;-)
> >Changes I've made since last time: I've messed (= probably broken
> >something) a bit with the deallocation of scalar INTENT(OUT) arguments
> >in trans-expr.c (gfc_conv_function_call), and tried to make sure
> >function results aren't deallocated until after they have been used.
> >
> >
> Yes, noted; see below for what I am now finding with the
> iso_varying_string testsuite.
>
> >+
> >+#if 0
> >+ case (SCALAR):
> >+/* This is horrible! FIXME. Problem with(eg.) vst_5.f95:205 */
> >+ goto get_me_out_of_here;
> >+#endif
> >+
> >+ case (SCALAR_POINTER):
> >+ tmp = build_fold_indirect_ref (tmp);
> >+ break;
> >+ case (ARRAY):
> >+ tmp = parmse.expr;
> >+ break;
> >+ }
> >+ tmp = deallocate_alloc_comp (e->ts.derived, tmp, parm_rank);
> >+ if (e->symtree->n.sym->result)
> >+ /* Don't deallocate function results until they have been used.
> >*/
> >+ gfc_add_expr_to_block (&se->post, tmp);
> >+ else
> >+ gfc_add_expr_to_block (&se->pre, tmp);
> >+ }
> >+
> >+get_me_out_of_here:
> >+
> >
> >
> Your activities have made this kludge even more necessary for the IVS
> testcases. I think that what you have done is correct and I am on to
> the reasons for it - or, at least, I have found that concatenation is
> the primary cause of the ICEs; eg. when concatenating two
> iso_varying_strings when one has zero length. The operation explicitly
> references outside of the allocated domain. Other compilers seem able
> to handle this, so I suspect that there is some trick that we are
> missing here. I can partially get round it by modifying the fortran in
> the iso_varying_string module. Whether this is a bug in the module or
> in gfortran, I do not rightly know yet.
OK. I haven't looked at the iso_varying_strings testcases thouroghly
yet. I guess I should, sooner or later.
> > /* Allocatable arrays need to be freed when they go out of scope. */
> >+
> >+ /* Paul had deledted this from here ... */
> >+ if (sym->ts.type == BT_DERIVED && sym->ts.derived->attr.alloc_comp
> >+ && !(sym->attr.function || sym->attr.result))
> >+ {
> >+ int rank;
> >+ rank = sym->as ? sym->as->rank : 0;
> >+ tmp = deallocate_alloc_comp (sym->ts.derived, descriptor, rank);
> >+ gfc_add_expr_to_block (&fnblock, tmp);
> >+ }
> >+ /* ... to here! */
> >+
> >
> >
> Rats! This was a desperate attempt to get to the bottom of the problem
> above. I never restored the code after the attempt - sorry!
Ah, OK. (This was something I had planned to ask you about at some point,
but then I just forgot completely about it. Sorry.)
> This is very good. If any of you out there are intersted in testing
> this patch, take a look at the code that the testcase produces! - I
> should explain that Erik has done all the tidy stuff; my contribution on
> the automatic deallocation is what produces the byte pollution...
Well ... I thank you for those kind words, but I think you are being
too modest!
> Erik, in conclusion; you do assignments and I do constructors?
Sounds OK to me!
Erik