This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]