C++ status (Was: GCC Status Report (2004-03-09))

["Giovanni Bajo" <giovannibajo@libero.it>]

Mark Mitchell wrote:

> Furthermore, please do not create any new PRs targeted for 3.4 without
> my explicit permission.  If it's a regression, target it for 3.4.1.
> If you think it might need to be fixed in 3.4, add me to the CC list,
> and add a note asking me to move back the target.  Please do not do
> this unless the PR is wrong-code, ICE-on-valid, or bootstrap for a
> primary target.  New PRs referring to other categories of error are
> simply not going to get fixed for 3.4.

Mark,

I understand your concerns to stabilize the 3.4 branch. Alas, at least from a
C++ point of view, it seems that the branch is nowhere near being stable. To
get some numbers, I tried counting the number of C++ regressions that were
found out and submitted since the beginning of February till today: they are
50, which roughly means one new regression uncovered each day (and yes, *valid*
regressions, I'm not counting bogus bug reports). Even if most of them are
usually handled within the same week they are submitted, this number is not
getting down yet. The more we fix, the more we uncover. I assume that this
number will have to decrease sooner or later, but this does not the case right
now.

My suggestions:

- I would strongly recommend 1-2 weeks of C++ freeze before release, to make
sure at least all important packages (the ones in the criteria) get properly
tested. This would help making sure that late patches did not uncover some
regressions. For instance, every other patch to the C++ frontend seems to break
Boost.Python somehow. Their authors are very prompt at testing and submitting
the new problems, though.
- Is it possible to at least get back all new C++ rejects-valid regressions to
a default 3.4.0 target? They look really important to me, especially since the
new parser is much strictier, so people will have already enough code to
modify.

For the longer run, I think the big problem is that the current g++ testsuite
(+ v3 testsuite) is not enough for testing C++ patches. I suggest we
incorporate bigger preprocessed sources from open source packages. I'm actually
already working on this, as Diego showed interest in having those in tree-ssa
before the merge for the benefit of additional testing.

Giovanni Bajo