Dear Janus, On Mon, Nov 7, 2011 at 12:14 AM, Janus Weil <ja...@gcc.gnu.org> wrote:
> The patch actually consists of two parts: > 1) The resolve.c part prevents the conversion to a PPC call via the > _vptr (for functions and subroutines). This is obviously OK > 2) The class.c parts prevents adding the non-overridable TBP to the vtable. > > As noted by Tobias, the second part breaks the ABI, so we might > consider deferring it until other ABI-breaking features will be > implemented (cf. http://gcc.gnu.org/wiki/LibgfortranAbiCleanup). On > the other hand, one could argue that the OOP ABI is still quite young > and hasn't really stabilized yet (it was broken already from 4.5 to > 4.6), so we might as well break it again. I know that there are a > couple of real-world codes out there, which make use of gfortran's OOP > features already, but I have a hard time estimating how many such > projects exists, or how problematic an ABI breaking would be for them > (user input welcome). Do we need to exclude it from the _vtable? I have to confess that, although I tried, I could not think of any reason to exclude it. On the other hand, I could not see any great harm in retaining a pointer, albeit a redundant one. > > So, the question is: Should I commit both parts, or only the resolve.c > one for now? The patch was regtested on x86_64-unknown-linux-gnu. In spite of the above remark, I think that you should commit both parts. Perhaps, until just before 4.7 release, a warning should be triggered that says that pre-existing code containing non-overridable procedures, should be recompiled before linking? OK for trunk. Thanks for the patch Paul
