This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unreviewed C++0x patches


On Thu, Mar 27, 2008 at 11:08 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Jason Merrill wrote:
>  > Mark Mitchell wrote:
>  >> If we're not going to fix a long-standing bug in non-0x mode because
>  >> it's not a regression -- even though it might affect relatively many
>  >> people
>  >
>  > I would be inclined to change that policy, too, as long as the patch is
>  > deemed safe enough.
>
>  I think that's a reasonable point of view, but I think we should decide
>  that issue first.  If we stick with the current policy, then making
>  changes for C++0x support seems odd.  If we change to a more liberal
>  policy, then it makes sense to include fixes for all features (including
>  very new ones like C++0x) in that.
>
>
>  >> then fixing C++0x bugs (which presumably affect fewer, given how new
>  >> it is), seems wrong.  We're introducing risk for relatively little
>  >> upside.
>  >
>  > I disagree.  Implementation experience is important to the
>  > standardization process; it helps a lot for GCC to be available as a
>  > sample implementation of some of the new features.  Though I suppose
>  > interested people could grab a snapshot of the trunk sources, that will
>  > mean a disconnect between 4.3 usage and eventual standardized usage.
>
>  Of course, GCC's mission is not to help with standardization.  By
>  actively pushing out pre-standard features we're actually putting our
>  users in harm's way; they're likely to end up with code that almost, but
>  not quite, matches the standard, and they may then need to change their
>  code as we change to match the eventual standard.
>
>  I'm all for using GCC to do research on new features and providing input
>  back to the committee.  But, that doesn't necessarily have to happen in
>  FSF releases; it can happen on branches.
>
>  All that said, I'm comfortable with accepting things after they make the
>  WP, which has been our informal approach up until now.
>
>
>  >> So, I think the bar ought to be very high.  In particular, I think we
>  >> ought to consider this only for silent miscompilation, and only if all
>  >> changes are isolated with C++0x conditionals.  And, if we're going to
>  >> consider these patches, then I think we ought to consider fixes for
>  >> other silent miscompilations as well, even if not regressions.
>  >
>  > I think we should consider those regardless of the C++0x issue.  I've
>  > expressed before my disagreement with placing higher priority on
>  > regressions than on wrong-code bugs.
>
>  I think that's the core issue here.  What do others think?

I think that wrong-code bugs, rejects-valid and ice-on-valid bugs are
important.  Very much so if they are also regressions.  I don't think
missed-optimization bugs or compile-time or memory-hog regressions
should have "advantage" before non-regression bugs in the former
categories.  Regressions that occur on branches are very bad,
regardless of category, though.

IMHO we should fix bugs in the first categories on branches regardless
if they are regressions or not - based on our belief that they do not
cause regressions on the branch.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]