[Patch, Fortran, OOP] PR 50919: Don't use vtable for NON_OVERRIDABLE TBP

Tobias Burnus burnus@net-b.de
Mon Nov 7 09:45:00 GMT 2011


On 11/07/2011 09:50 AM, Janus Weil wrote:
>>> As noted by Tobias, the second part breaks the ABI ... 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.
> Well, no, there is no hard reason why we *need* to exclude it. The
> point is that, given we call these non-overriable procedure in a
> "non-vptr" way, there is no need to have them in the vtable either ;)
> .... except for "historical" / ABI-compatibility reasons.
[...]

> In fact I'm not sure whether it is so easy to produce wrong behavior
> at all, combining code parts that were compiled with different
> gfortran versions (4.6/4.7). Since the vtabs are supposed to be
> 'global', usually there should be only one version of them generated
> in the main program (at least that is how it's supposed to be, but
> probably that does not work in *every* situation yet). I will try to
> see if I can find with a failing code example. (The issue is of course
> that if the vtabs change their contents between 4.6 and 4.7, a
> type-bound call could end up calling the wrong procedure).
>
> Moreover, I have the feeling that NON_OVERRIDABLE is not so widely
> used "in the wild" (but that is just a feeling, of course).

I concur that it is not that simple to produce a failing example. The 
only solid example where it really matters is a closed-source library 
which comes with a .f90 file which contains the module information, 
which is needed to to produce the .mod files.

All other ideas are based on some careful recompilation and relinking, 
which avoids touching the .mod files, which is possible but either 
nontrivial or unlikely. Example: Recompiling the library and using it 
with an old program - for instance as shared library or by mere relinking.

Note that the issue won't go away soon. We will have for years 
installations which have 4.6 and some which have 4.7 or later (e.g. with 
some OS update). Thus, one should be careful with the argument that 
there are not so many non_overridable programs in the wild as that might 
change in the next years. Though, it might take a while longer until the 
users realize that non_overridable provides a performance advantage. (By 
the way, PSBLAS does not include non_overridable.) -- Additionally, I 
*do* see a difference between GCC 4.5->4.6 and 4.6->4.7. There were many 
issues with OOP in 4.5, which made it difficult to use it. By contrast, 
OOP in 4.6 is usable - there are some issues (operators, polymorphic 
arrays, constructors, final) but they are not preventing its usage.

Unfortunately, having a different vtable will not produce compile- or 
link-time failures but will often cause that the wrong TB procedure is 
started (possibly with all kind of argument-value/presence issues) or 
might segfault immediately.

Thus, I believe it is rather difficult to run into the ABI issue in the 
real world (due to technical but also due to usage reasons), but it is 
possible. Hence, I wanted to point out that there is an ABI issue, but I 
also don't oppose the committal as it is difficult to encounter the 
issue - both in practise but also with an constructed example.

Tobias



More information about the Gcc-patches mailing list