Re: [PATCH] Implementation for ALLOCATE(..., SOURCE=expression)

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Steve,

> First, a big 'thank you' to pault for the trans-stmt.c portion
> of the patch.  I was stuck on translation to trees for a long
> time; something about a forest and too many trees.

You're welcome - the ChangeLog attribution is excessively kind,
relative to the effort that it took.  It so happens that I had done
that particular job several times previously.

> succeed with the intrinsic-type-spec matching, I introduced a new
> function to match only F2003 intrinsic-types-specs, which is a
> stripped down version of gfc_match_type_spec().  gfc_match_type_spec()
> has grown too many special cases and it's use in gfc_match_allocation()
> led to 2 regression that I simply could not fix.

I worry about this bit.  What were the regressions and why could they
not be fixed?  I am concerned because we will have to introduce
derived types and so will wind up essentially reproducing
gfc_match_type_spec.

I think that we should admit the patch as it stands, so that it gets
shaken down properly and should agree to eliminate this new function,
in favour of gfc_match_type_spec in the medium term.

> Regression tested on i686-*-freebsd.
>
> OK for trunk?

OK, subject to the above remark.

Many thanks

Paul