No patch review - but and answer to a question and a comment.
Janus Weil wrote:
> I am aware that it will break the ABI, but only for programs involving
> procedure pointers (which still is a 'relatively' new feature,
> supported since gfortran 4.4).
>
> Btw, speaking of ABI breaking: What are the chances of the array
> descriptor update and ABI cleanup happening for the 4.8 release? I
> know such an ABI breaking has been planned for some time, but I
> haven't followed the gfortran mailing list in detail during the last
> weeks and months, so I'm not sure what the current status is.
Regarding Fortran-dev (which contains the new descriptor): On the branch,
the new dimension triplet (lbound, extent, sm [stride multiplier in bytes])
is used - instead of the old (lbound, ubound, stride [in # of elements]);
there are still about 20 failures.
The next step is to reduce them to zero. Half of them are due to c_f_pointer;
I have a draft patch for it [moving it from the library to the compiler], but
it still fails in an odd way. The other issues haven't been debugged.
Additionally, one needs to do some optimizations - Thomas' patch is the first
step into that direction.
We then also have to do further changes to the other fields of the descriptor.
I have no idea whether it will be ready until the 4.8 release. It is doable,
but quite a lot of work needs to be done. Especially as we want to do some
additional cleanup. However, there are also other gfortran projects which have
to be worked on.
My personal guess is that the array descriptor will be mostly but not
completely ready by the end of Stage 1 and thus be deferred another year.
However, as the saying goes: "Prediction is very difficult, especially about
the future." (Possibly by Niels Bohr, who might have taken it from the
Danish poet Piet Hein, though the source of the quote is disputed.)
* * *
Regarding ABI breakage:
I strongly propose that we - starting from 4.8 or starting from the
array-descriptor ABI breakage - keep backward compatibility for the .mod files.
That is, if the mod version is bumped, the compiler shall be able to read the
previous version.
And unless the ABI is serverely remodelled as with the array descriptor: We
should try to avoid ABI breakage and if it is needed as for the procedure
pointer,
we should do the same as GCC's C++ compiler:
-fabi-version=n
-fabi-version=n
Use version n of the C++ ABI. Version 2 is the ver-
sion of the C++ ABI that first appeared in G++ 3.4.
Version 1 is the version of the C++ ABI that first
appeared in G++ 3.2. Version 0 will always be the
version that conforms most closely to the C++ ABI
specification. Therefore, the ABI obtained using ver-
sion 0 will change as ABI bugs are fixed.
The default is version 2.
Version 3 corrects an error in mangling a constant
address as a template argument.
[...]
See also -Wabi.
Regarding:
> I am aware that it will break the ABI, but only for programs involving
> procedure pointers (which still is a 'relatively' new feature,
> supported since gfortran 4.4).
That's already supported since 3 years - and there are several programs out
there which use it, given that is was somewhat stable. gfortran escaped some
issues by always bumping the .mod version (due to new features), which made it
less likely that a user could run into issues. We also fixed some very special
corner cases - in particularly with truely new features. But I don't think
that proc-pointers count in this regard: They are too widely supported by old
gfortran versions and by other compilers and proc-pointers as module "variable"
is not really a corner case.
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?
Tobias
