http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-20 11:22:37 UTC --- (In reply to comment #2) > I agree completely. However, once 4.7 is released, should we be excessively > pristine about ABI breakage in trunk? It is, after all, the development > version and, to some degree, if people use the development version for > production code they should be mindful of the risks.... Well, the point is that code (e.g. libraries) compiled with GCC 4.3/4.4/4.5/4.6/4.7 shall be linkable with code compiled with GCC 4.8. In particular, ABI changes relative to Fortran 77 ABIs should be avoided. (libblas, liblapack, ...) - as they are truly used with many applications and as there also no .mod file is involved. For experimental code - such as -fcoarray=lib -, we have more leeway, but for code which is used in production, we shouldn't break the ABI. As the .mod format changes with every release, the chance that the user runs into ABI problems is a bit reduced as for type declarations, one has to recompile to get a new .mod file. However, one can still construct cases where ABI issues also occur in that case. (libA and libB compiled with 4.7; libB uses libA; libA recompiled with 4.8 and then linking libA, libB and the application. If libA and libB use a feature for which the ABI has changed, it will break at link or run time.) The g++ compiler - where the .mod issue does not exist and where many more application use C++ libraries, the ABI issue is much greater. g++ has the -fabi-version=... flag to toggle between different ABIs and -Wabi to warn about such issues. In case of the new array descriptor, the ABI change is so big and affecting many programs, that it cannot be avoided. Thus, doing so, bumping the .so version number and using the opportunity for a clean up should be done. However, afterwards, we have to try hard to avoid any ABI breakage and it would be good if .mod files from a previous compiler version would continue to work. Thus, we should either have the modifications in an upward compatible way - or we should build in some way to read old versions, by explicitly skipping new features during read in. (As we know the version number - we can make use of it!) The .mod part is not an issue for the first version with the new descriptor - as we have to break the ABI. If we include the new array descriptor in 4.8, I think for 4.9 we should already have the policy that no module.c change is allowed, unless it is done such that .mod files from 4.8 continue to work.
