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:35:32PM +0100, Richard Guenther wrote:
> On Thu, Mar 27, 2008 at 11:08 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> > Jason Merrill wrote:
> >  >> 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.

Yes, especially wrong-code non-regression bugs are IMHO often more important
to get fixed than other category regressions.  With rejects-valid and
ice-on-valid we need to weight the risks of the patch against how likely is
people hit those bugs (e.g. corner cases with risky patches are undesirable
on the branches, while something that people can hit fairly often is of
course much more desirable to get fixed on the branches).  As an example,
while OpenMP 2.5 support isn't already new feature (it has been already in
4.2.0), wrong-code/rejects-valid/ice-on-valid bugs are still being reported,
and most of these are not regressions, yet are very desirable to get fixed
even on the branches.  Most of the fixes are in OpenMP only code, so
shouldn't affect -fno-openmp stuff.  I think C++0x is similar, with the
notable difference that many of the language constructs are enabled even in
the default -std=c++98 mode, just with warnings.  Technically any ICE
on this in -std=c++98 mode is an ice-on-invalid regression, though it is
very unlikely people will use those C++0x constructs in their
C++98 code and expect to get errors, much more likely is that they are
actually playing with C++0x.  So, if the C++0x
wrong-code/rejects-valid/ice-on-valid bugs just affect code that uses
C++0x constructs, no matter whether it is in -std=c++0x or -std=c++98
mode, I think we should consider such fixes for the release branches.

	Jakub


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