[Patch, Fortran] OOP: merging fortran-dev to trunk?

[Janus Weil]

Hi all,

I would like to discuss here the current state of the OOP features in
gfortran. As you know, Paul and I have started some time ago to attack
F03 object oriented features (CLASS, polymorphism, ...). A lot of this
work has gone into trunk already, where simple polymorphism is working
but many problems persist. For an overview see
http://gcc.gnu.org/wiki/OOP.

On top of the basic features which are on trunk, we have been working
on the more advanced stuff (including an improved internal
representation) on the fortran-dev branch. The stuff which is on the
branch now (i.e. mainly EXTENDS_TYPE_OF and SELECT TYPE with CLASS IS)
has been lying there for quite some time and has received a good
amount of testing (many thanks to Salvatore and Damian, who were the
main beta testers and did a great job). I would say the fortran-dev
branch can be regarded as rather stable (e.g. it nicely compiles
Salvatore's huge PSBLAS library, which makes heavy use of the new
features).

Furthermore, Paul has been working very hard on an improved
representation of polymorphic type-bound procedures (for which he uses
procedure pointer components in the class container), but
unfortunately this is not stable enough yet and has not been committed
to the fortran-dev branch.

I have been discussing quite a bit with Paul and Tobias on how to
proceed. It's a bit of a nasty situation, since we do have *some* OOP
in 4.5, but for sure it won't be perfect. [One of the most tricky
aspects is that there are situations where compilation goes through
fine, but stuff fails at runtime (cf. PR41829). These issues are the
same on the trunk and fortran-dev.]

My proposal would be to merge the current state of fortran-dev to the
trunk now, and leave the advanced TBP stuff that Paul is working on
for 4.6. As I said, the features on the branch can be considered to be
rather stable (the more experimental stuff has not been committed
yet), and most of it is rather low-risk wrt regressions, since it is
hidden behind BT_CLASS guards.

I am aware that we're in late stage 3, and that this is not a trivial
patch (the diff between fortran-dev and trunk that I'm attaching is
about 70k, including test cases). So, we should discuss whether we
want this or not. From my point of view, the benefits outweigh the
risks, but of course we need to decide this as a community.

Please let me hear your opinions.

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fortran-dev_091130.diff
Type: application/octet-stream
Size: 70695 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091130/ce48bda2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ChangeLog.fortran-dev
Type: application/octet-stream
Size: 3204 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091130/ce48bda2/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ChangeLog.fortran-dev
Type: application/octet-stream
Size: 715 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091130/ce48bda2/attachment-0002.obj>