[Patch,Fortran] PR39427/37829 - implement F2003's constructors

[Paul Richard Thomas]

Dear Tobias,

I'll take a look this afternoon.

Cheers

Paul

On Mon, Nov 14, 2011 at 10:45 AM, Tobias Burnus <burnus@net-b.de> wrote:
> I would like to *ping*.
>
> Additionally, I attached an updated patch as the tree-walking patch is now
> in. The updated patch is also available at
> https://userpage.physik.fu-berlin.de/~tburnus/tmp/constructor.diff
>
>
> On 11/06/2011 04:29 PM, Tobias Burnus wrote:
>>
>> this patch fixes as collateral effect PR 37829 (alias PR 45190) where
>> C_PTR/C_FUNPTR occurred when use associating a module using them, if one
>> additionally uses iso_fc_binding directly.
>>
>> The main part of this patch, however, is for PR 39427 (alias 45190):
>> Allowing generic functions to have the same name as a derived type, which is
>> a Fortran 2003 feature. In expressions, the generic functions have a higher
>> precedence then the structure constructor. Note that the functions are not
>> required to return the derived type.
>>
>> This feature allows one to create something which looks similar to
>> constructors in other OOP languages, except that static constructor
>> functions do not exist.
>>
>> This patch implements them by creating for each derived type two symbols
>> (symtrees): One for the derived type and one for the generic function, which
>> links to the derived type. To distinguish them, the derived type starts with
>> a capital letter in the symtree. In order to facilitate the error-message
>> handling, the symbol itself remains in lower case.
>>
>> The main challenges were to ensure that one gets the derived type when
>> needed and to store them properly in the module. The most time consuming
>> part was to find all the places one had to change that issues with module
>> reading could turn up much later; for instance at resolution time of a scope
>> which had read that module. In total, it took 18 months between the first
>> draft patch (cf. PR39427 comment 6, 12-14) and the final patch. Although,
>> the patch looked almost working by then, it took many, many, many hours to
>> fix the issues. Also the RFC patch, posted 6 days ago, had more issues than
>> I had hoped for.
>>
>> The attached patch had been build on x86-64-linux and successfully
>> regtested (gfortran and libgomp). (A full bootstrap of an almost-ready
>> version was done as well; I had to rebuild because I found some left-over
>> commented code blocks.)
>>
>> Additionally, I tried the previous patches with several programs to reduce
>> the likelihood that it breaks real-world code. In particular, the very
>> latest version of the patch was used to compile FLEUR, Elk, Octopus and the
>> Polyhedron benchmark. Yesterday evening's version was used to compile the
>> Exciting code (which includes the sensitive FoX Fortran XML library), CP2K,
>> PSBLAS and FGSL. With a slightly older version, I also successfully compiled
>> Tonto, Quantum Espresso and Abinit.
>>
>> OK for the trunk?
>>
>> Tobias
>>
>> PS: I have also included a patch for the website, i.e.
>> http://gcc.gnu.org/gcc-4.7/changes.html#fortran
>>
>> PPS: As mentioned in the attachment, the patch includes the tree-walking
>> patch, which was posted before. It's a really an independent bug, even if it
>> only exposed with the constructor patch. I can either commit it before or as
>> part of this patch. See also
>> http://gcc.gnu.org/ml/fortran/2011-11/msg00026.html
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy