This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Bravo! Thanks for all the hard work, Tobias.

Although I realize many people will (correctly) label the constructor
capability as syntactic sugar, it supports an idiom that is common across
OOP languages as you point out.  Common idioms have expressive power.

Damian 

On 11/6/11 6:29 AM, "Tobias Burnus" <burnus@net-b.de> wrote:

>Dear all,
>
>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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]