On 6/8/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> In the interests of moving forwards, I therefore plan to close this
> exceptionally long Stage 1 as of next Friday, June 15th. The projects
> named above may be merged, even though we will be in Stage 2 -- but no
> other functionality of Stage 1 scope may be included after this point.
An additional project, which is not on your list and perhaps should be:
[snip ISO_C_BINDING stuff]
In any case, I very strongly believe that this should be included in
4.3, and would hope that if the review process takes a couple of weeks
that it can still be merged in.
I agree. This is definitely a major feature for gfortran, and it seems
that it's really close to being ready for merging. It would be a shame
to let this slip for another year.
Now, to my actual point. I'd like to propose another project worthy of
inclusion, or actually a number of smaller projects. As of 4.3 the
gfortran runtime library will have versioned symbols. This means that
if we're going to provide some semblance of ABI stability to our
users, we have until 4.3 to do any ABI fixes we feel necessary or
useful. After that we're stuck with supporting the old ABI for the
foreseeable future. Now, of course one of the benefits of versioned
symbols is that we can keep supporting the old ABI as we add improved
functionality to newer ABI versions, but the less cruft we have to
drag along, the better for us from a maintenance perspective.
Most of these ABI cleanup patches would be pretty small and mostly
mechanical, so I don't think there's a large risk that we'll introduce
regressions. For a recent example, see e.g.
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00479.html
Daniel Franke recently committed some infrastructure to enable the
frontend to typecast intent(out) intrinsic arguments. This allows us
to fix some ABI issues for intrinsics, where we have a lot of
unnecessarily duplicated functions in the library, and also helps us
avoid a combinatorial explotion that would result in supporting all
type kinds for many arguments to some intrinsics. Of course, for some
performance sensitive intrinsics we still want the library to have
specific versions for different type kinds.
--
Janne Blomqvist
