.mod file compatibility

[W Spector]

Hi Tobias,

First, thank you for the thoughtful response!

I fully appreciate the desire to bump the .mod version when the ABI 
changes to better support some feature.  But it seems like there are 
often ways the incompatiblity could be managed such that only codes 
which actually used area where the ABI was changed need to be recompiled.

One commercial example I can point to is Intel.  As I understand it, 
their current compilers can still read most .mod files back to their 
v8.0 (about Y2K time frame) release.  There are a few well-documented 
hickups along the way.  So users using certain specific features do need 
to recompile.

The code base I currently work with sticks fairly closely to F90/F95 
exactly because full F2003 support of various compilers is still so 
iffy.  It is very frustrating because there are a lot of great F2003 
features that we would like to use.  But heck - we still find occasional 
F95 bugs in various compilers and end up backing out perfectly legit code.

In the potential v4.10 case, where you are looking at changing the array 
descriptors, it seems like the compiler could pass either an old 
descriptor or a new descriptor - based on whether an old .mod or a new 
.mod describes the callee.  Just an idea.  However I can easily think of 
situations where supporting multiple .mod levels simultaneously could 
potentially get out of hand.

Walter

On 09/06/2013 11:39 AM, Tobias Burnus wrote:
> Hi Walter,
>
> W Spector wrote:
>> Does anyone have a table documenting which versions of gfortran can
>> read .mod files created by older versions of gfortran? I note that on
>> the main gfortran wiki page, both gfortran 4.8 and 4.9 have
>> compatibility notes concerning .mod files. But what about older
>> versions?Generally, it would be very helpful if newer gfortrans could
>> continue to read .mod files created by older versions. The current
>> situation creates a real maintenance hassle when mixing products that
>> were built at different times by different teams.
>
> I think so far every new major version (4.x.y, x being different) was
> incompatible with older versions.
>
> I concur that it is very inconvenient that different versions have
> incompatible .mod versions. I was actually considering to push for
> backward compatibility - at least in the sense that one can read older
> .mod files. (For the problems with that see below.) Additionally, I
> thought that it would be useful to document the compatibility (or their
> lack of) in the release notes. That's the reason that you find for 4.8
> and 4.9 a complete list. The situation is not much different in older
> versions.
>
> One (bad?) reason to bump the .mod version was lately ABI changes - and
> bbumping the mod version is one way to enforce that. That might be not
> the user friendliest way but crashes due to ABI changes are bad, too.
>
> The ABI changes were all related to Fortran 2003/2008 features. For
> instance, the latest change was the support for finalization. There, one
> has a virtual table, which contains all the type-bound functions which
> are associated with the (effective) type. Rather at the top, a new entry
> for the finalization wrapper functions was added. The problem is that
> without a full recompilation, one would either call a user-defined
> function as a finalization wrapper - or the finalization wrapper instead
> of a user function. Either leads to segfaults. That's the main reason
> behind the 4.9 .mod version bump. (Additionally, .mod files are not
> compressed, but that would only cause problems with older gfortrans
> reading newer .mod files.)
>
> In terms of the future: We are aware that compatibility is important.
> That encompasses:
> a) The library. Since 4.3 (if I recall correctly), the library itself is
> upward compatible. That is: older programs continue to work with newer
> libgfortrans.
> b) The ABI itself is mostly stable, the older the feature, the stabler
> it is. (Fortran 77 features see fewer ABI changes than F90, F90 fewer
> than F2003.)
> c) The file format of binaries, the command line options
> d) The .mod file
>
> On the other hand, presumably in the next development cycle (4.10?),
> there will be a large ABI breakage: gfortran will move to a new array
> descriptor. As this is at the heart of gfortran, there will be no
> backward compatibility with Fortran 90 programs. As result, expect a new
> libgfortran library version number and a new .mod version. The new array
> descriptor is required to implement some corner cases of Fortran 90. It
> is also required to support rank >7 arrays and for TS29113. Actually,
> the format will nearly exactly match the one of TS29113. (See
> fortran-dev for a 70% complete version.) – Additionally, one can then
> use the opportunity to clean up the library and do other ABI breaking
> things, which one didn't do before to keep backward compatibility.
>
> I do hope that after the array descriptor reform, the .mod versions will
> stay the same (or backward compatible) for a longer time and that also
> no ABI breakage will be required, but only the future will tell whether
> we will manage to do so.
>
> Tobias
>