Hi Janus,
On 04/11/2012 10:58 AM, Janus Weil wrote:
Hence, we should really think about -fabi-version=<n> (and .mod compatibility).
Unless, we are positive that we will break the ABI for the array descriptor in
4.8, I am in favour of adding -fabi-version=<n> already for the proc-pointer
patch.
Comments?
well, my feeling is that adding an "-fabi-version" machinery just for
the proc-pointer problem would be overkill
It might be - but we do have to worry about the ABI. We can decide that
it may not matter in this case, but users and even more distributors do
care about a stable (or backward compatible) ABI and a stable (or
backward compatible) .mod format.
1) Different assembler names for proc-pointers will usually result in
linker errors, when mixing code compiled with different gfortran
versions. So at least the user knows that there is a problem and will
not silently get wrong results or random segfaults (as it probabably
would be the case for mixing different array descriptor versions).
True. Thus, the array descriptor change is really disruptive. However,
that does not mean that others aren't affected by other ABI changes.
2) Although proc-pointers have been supported by gfortran for about
three years now, I don't think there are many libraries around which
use proc-pointers and are redistributed in binary form. So I would not
see this as a major problem (but maybe I just underestimate this
issue).
I concur that in this case, the problem is less likely to occur - due to
various reasons. I am not arguing that we have to add -fabi-version=,
but we should seriously considering doing so and in either case ABI
change should be documented in the release notes.
Additionally, besides the case of having no access to the library, the
case that a pre-compiled library exists is not that low. At least if
you work under Linux, where the distribution or some third party
already has builds. Or if you work on a HPC system where the admins have
precompiled libraries. (For instance, I have never compiled ScaLapack my
self.)
3) As you mentioned, the .mod version incompatibility also severely
limits the mixing of code compiled with different compiler versions.
And the proc-pointer name mangling (which is under discussion here)
*only* concerns proc-pointers inside modules.
Note however, that GCC 4.7 and 4.8 do share the same .mod version!
In general: Is ABI ompatibility of different gfortran versions important to
gfortran
users? (For me personally, as a user, not so much. I usually don't link my own
code with pre-compiled Fortran libraries).
For me it is very important. Fortunately, most Fortran libraries do not
use modules and are thus not affected by .mod version issues. There are
several closed-source libraries and programs. (For the latter,
compatibility matters as they might be only dynamically linked to
libraries such as LAPACK.) One library, which I use, is AMD's math
library. And I know that AMD was struggling before with ABI issues.
Namely, they had to decide which gfortran version thy should be build
against. Since libgfortran is now backward compatible down to 4.3, they
are fine at the moment.
The other libraries I use are installed either via the Linux
distribution or by the HPC admins. Those include BLAS, LAPACK,
ScaLAPACK, MPI, HDF5, NetCDF, libxc. Some of them ship with .mod files
and I have heard several complains about their incompatibility. Both
from users and from Linux distributions.
Frankly, I do not know whether, e.g., libxc uses proc-pointers on module
level or not. Probably none of the libraries I use would be affected -
and if, those probably have their source-code available.
To conclude:
* ABI compatibility - especially for libgfortran - is very important
and Linux distributions, HPC centers and closed-source software
distributors rely on it. (Also users expect that their old program still
runs after an updated - also on systems where no .so versioning is
possible. [Think of Windows.])
* .mod incompatibility seems to be less an issue, but it also causes
grieve for users and distributors. As modules (and other F90+ features)
get more widely used, the problem will grow.
The question is also: Should I rather commit the patch to the branch,
so that it will only be merged to trunk together with the new array
descriptor (once it is finished)?
Regarding your patch, I see three options:
a) Committing it to the branch. Pro: No ABI breakage through the patch
as the current branch already will break the ABI.
b) Committing to the trunk as is - but with a note in the release notes.
c) Ditto but with backward compatibility through -fabi-version=
Given that it is unclear when the branch will be ready, I prefer (b) or (c).
And I would like to see others commentin on ABI and .mod compatibility
and also -fabi-version= *in general*. Plus comments whether (a), (b),
or (c) is the best choice for *this* patch.
Tobias
