This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules
>> 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
>> 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).