[Patch, Fortran] Calling type-bound procedures

[Daniel Kraft]

Paul Richard Thomas wrote:
> First, please accept my congratulations for a truly magnificent bit of
> work!  I know that Daniel has done most of the labour but, in my
> absence, Tobias has done an excellent job with the reviews, testing
> and standard control.

Hi Paul, welcome back!

>>> this is the cleaned-up version of my patch to allow for calling
>>> type-bound procedures posted yesterday including a ChangeLog.
>> As a small thing: I think one should update dump-parse-tree.c; I think
>> everyone tends to forget it and it is almost never used.
> 
> Absolutely right!  In fact, I use -fdump-parse-tree a lot and it
> certainly needs all sorts of f2k features to be added.  One example is
> EXTENDS!
> 
> I wonder if we will not need to change the format?  I guess that the
> additional features will make the dump seriously incomprehensible:-)

See my other mail, but I want to look into this and try to get it 
somewhat usable in a follow-up including documentation to 
gfc-internals.texi.  Is this ok for you?

BTW, I always found the format already incomprehensible...  But I've 
used it a few times myself for finalization work.

>> I like your patch. However - thanks to NAG f95 - I just realized that we
>> currently cannot implement PASS in a standard conforming matter. The
>> reason is:
>>
>> C453 The passed-object dummy argument shall be a scalar, nonpointer,
>>     nonallocatable dummy data object with the same declared type as
>>     the type being defined; all of its length type parameters
>>     shall be assumed; it shall be polymorphic (5.1.1.2) if and only
>>     if the type being defined is extensible.
>>
>> The problem with PASS for all type-bound procedures and for procedure-
>> pointer components in non-SEQUENCE, non-BIND(C) procedures is the
>> following: The type needs to by polymorphic, i.e. instead of
>>
>>  TYPE(mytype) :: dummy_arg
>> one needs
>>  CLASS(mytype):: dummy_arg
>>
>> Thinking about it, it makes sense: Unless the procedure is overwritten,
>> the type%inherited_proc() won't work. (I have not checked what happends
>> currently.)
> 
> I suggest that we continue to allow this temporarily and emit a
> warning.  That way, all the hooks are there and we can correct it as
> soon as......

Done.

>> Somehow type-bound procedures without PASS loose a lot of their
>> usefulness. Except for this point I think the patch is OK.
> 
> I agree.
> 
> +      /* XXX: Should I replace the gfc_error_now above by a gfc_error?  This
> +        should be possible by some (not much) effort with returning an
> +        optional gfc_try FAILURE here.  */
> 
> I think that is what you should do.

Done.

Attached is a new patch that addresses those two points as above, 
otherwise no changes.  Regression-testing running on GNU/Linux-x86-32.

Ok to commit if no new failures?  After that I'll start the 
documentation work for this pieces.

Thanks,
Daniel

-- 
Done:     Arc-Bar-Cav-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
To go:    Hea-Kni-Mon-Pri-Ran-Rog-Tou
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.changelog
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080829/9a5a5789/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080829/9a5a5789/attachment-0001.ksh>