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
