>> 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!
at least up to now, but the 4.8 trunk is still young and a lot can happen until the release ... > To conclude: > * ABI compatibility - especially for libgfortran - is very important and > Linux distributions, HPC centers and closed-source software distributors > rely on it. I certainly agree with this general statement. On the case of '-fabi-version', I would conclude: * For the proc-pointer problem at hand it would be easy to implement, but not extremely useful. * For the array descriptor it would be much more useful, but also a lot more difficult to implement. Do you think it would be feasible at all? I'm not an expert on array descriptors, but I imagine it would be a huge amount of work to properly support two versions of the descriptor?!? >> 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). I don't really like (c), so I'd vote for (a) or (b), which puts (b) in the pole position for now ;) (a) would also be acceptable for me. Although it could delay the proc-ptr fix, it would guarantee that we break the ABI only once (preferably in 4.8 together with more ABI cleanup). Cheers, Janus
