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 issue). 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)? Cheers, Janus
