Should patches for PR target/1532 go on 3.4 branch?

Ian Lance Taylor ian@wasabisystems.com
Thu Feb 12 19:41:00 GMT 2004


"Giovanni Bajo" <giovannibajo@libero.it> writes:

> > Hmmm, interesting.  There are several PRs which have a target of 3.4.0
> > but which don't show up on your list because they do not have 3.4 in
> > the subject line.  This includes some critical PRs like 11326 and
> > 13316 (I submitted the latter) which are not regressions but are ABI
> > issues and as such should be considered before a release.
> 
> There are many critical issues with GCC, but it's generically too late for 3.4
> to consider non regressions. If a bug is not a regression, it means that it was
> tested up to 2.95 and all the versions were affected the bug. Which means that,
> even if it's an important bug, it's very very unlikely that code exists which
> is broken by it. It might have been worked around years ago already. Of course,
> a critical bug is important to fix in mainline. But release branches should
> focus on fixing regressions, i.e. not breaking existing and working code.
> 
> In other words, I don't see anything wrong with Mark's way of checking for bugs
> to be fixed before 3.4.0.

I more or less agree with you except for ABI changes.  I think those
really are critical--it at least critical for somebody to make an
informed decision as to whether to continue with a broken ABI or not,
or to decide that the ABI is not broken at all.  In other words, I
think it is critical to fix or close all ABI PRs.

We are already changing the default C++ ABI between 3.3 and 3.4.
Every ABI change is a serious inconvenience for all C++ users.  If we
don't consider, e.g., PR 13316, then we're setting ourselves up to
seriously inconvenience C++ users again.  That would be bad.

To put it another way, not making an ABI change is not going to cause
a regression now--how could it?  But if we make the ABI change later,
we are going to cause a regression later, when people discover that
they must recompile their existing libraries.

On a bureaucratic paperwork level, I think that if there is a PR with
a target milestone of 3.4.0 which is not showing up on Mark's list,
and which presumably is therefore not expected to be fixed on the 3.4
branch, the target milestone should be changed to 3.5.0.  Of course,
such a change should only be made in an informed manner, with Mark's
concurrence.

Ian



More information about the Gcc mailing list