Hi Tobias,

> 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, because ...

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).

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

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.

I would surely appreciate some input from others, also from users (in
particular from Andrew as the bug reporter). In general: Is ABI
compatibility 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).

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)?


Reply via email to