This is the mail archive of the 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: 3.4 regressions: are 2.95 regressions still actual

"Giovanni Bajo" <> writes:

| open. It never worked, so there is no existing code which is affected by it.

I think that part of the reasoning is too quick.  If there is a
report, then presumably it is because an existing code is affected.

What we may consider though, and I guess that is what Erik was trying
to say, is when a (non-regression) bug is fixed in mainline it might
make sense to backport a corresponding patch to a branch.  That might or
might not be feasable depending on the fix.  If the fix is too invasive,
then most certainly the bug will remain unfixed til the next major

| The bug is useless for GCC developers, as from their point of view it's
| something that doesn't need to be touched:

  And we ought to consider whether we develop GCC for GCC developers only.

The point I'm trying to make is that, sometime it is not really
desirable to upgrade to the next major release -- for several reasons
(ABI compatibility is a good one) -- just to get a bug fixed.  If it
is really the case that the bug is nasty (like those many the new
parser fixed) then it makes the most sense to close the bug as "fixed
in x.y, won't fix in x.s.t".  However, some bugs can, technically, be
fixed on branches through safe backports.  I think those should be
given some considerations through less hard-and-fast rules.    

| it will just work in the new
| version. Plus, CVS branches are open for regression-fixes only, which means

I think, it depends on the policy the RM set.  For 3.3.x, I've set it
that a month before the putative release date, the branch is open to
all "safe" bug fixes.  After that point, only regression fixes are

| that it's disallowed to commit bug reports for anything but
| regressions (unless the RM wants to override this policy for some
| specific case). 
| If you disagree with what was done with your bug, just give me the PR number
| and we can revisit the situation just now.

I believe we ought to come up with a more general rule than "if you're
not happy, gimme your PR number".  The reliable reach of this list is
orders of magnitude less than the GCC user community.


| > (Hypothetically,
| > one could even check whether these bugs actually stayed fixed in the
| > 3.4 branch.)
| This is done through the testsuite. Sometimes things get fixed thanks to
| changes which already have entries in the testsuite. Other times, some peculiar
| ICE gets fixed just by chance, and in that case we close the report but we *do*
| add a testcase to the testsuite.

Fully agreed.

-- Gaby

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