GCC 4.1 Status Report (2005-08-21)

GCC 4.1 Status Report (2005-08-21)

[Mark Mitchell]

I've reviewed all 311 bugs that were targeted at 4.0.2/4.1.0 and that
were marked as 4.1 regressions.

My first comment is that we had a lot of bugs targeted at 4.1.0 that
should never have been so targeted.  Please remember that bugs that do
not effect primary or secondary targets should not have a target
milestone.  There are several PRs that seem to have had target
milestones re-added after I removed them before, though it could also
be that I failed to remove the milestone, even though I added a
comment to that effect.  PR 17356 is an example of such a PR, though
in this case it looks like it was Andrew Pinski who removed the target
milestone.  PR 18190 is another example.  In fact, it almost looks
like someone went through and methodically re-added target milestones
to all the PRs for which they had been removed.  If that's the case,
please stop!

After removing target milestones for bugs that appeared to have been
spuriously marked, there are 271 bugs targeted at 4.1.  (I left a few
bugs that seemed to refer to languages/platforms that aren't
release-critical, on the grounds that the bugs seemed to reflect
generic problems, but I may remove even these as we move forward,
unless C/C++ examples are added that demonstrate the genericity.)

Of these, 91 are wrong-code (26), ice-on-valid, or rejects-valid.
That's not too bad.  There are a lot of C++ bugs -- but most are ICEs
or bad/missed error messages.  (Quite a few of the diagnostic messages
stem from the design decision to issue warnings from the
optimizers...)  There are a lot of missed-optimization bugs that
represent regressions.  There are the usual cast of bugs relating to
extensions, including things like supporting C99 features in C++.

Although, overall, I feel pretty good about the fact that the
*severity* of most of the open bugs is not too high, I'm not happy
with the overall *quantity* of bugs.  In the past, we've aimed for 100
open regressions before making the branch, and I don't think that's an
unreasonable target.  Therefore, as I hinted earlier, I think Stage 3
is going to have to slip.

However, if ten people commit to fixing a regression a day, we should
be able to reach 100 bugs in about three weeks, even allowing for some
new bugs popping up as we go -- which would put us at mid-September.
The most important thing is that people stop working on clean-ups and
new features -- and truly concentrate on fixing bugs.  I don't want to
be draconian about that, but let's get the bugs fixed.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 4.1 Status Report (2005-08-21)

[Andrew Pinski]

On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:

> (Quite a few of the diagnostic messages
> stem from the design decision to issue warnings from the
> optimizers...)

Only 8 out of 49 at that, though some are very minor as two are just
complaining wording of the warning.  And almost all are uninitialized
warnings which are always questionable as there is no way to warn from
the front-end without flow control. In fact all those 8 are either
unreachable code, uninitialized, or return.  All of which can be shown
have to be done with control flow.

If you take the following example (for unreachable code):
void f(void)
{
   goto a;
b:
   goto c;
a:
   return;
c:
   goto b;
}

There is no way to know that the "goto c" and "goto b" are dead without
some kind of control flow.

I don't think singling out these 8 are useful.  Considering 28 out of 49
are C++ bugs and at least one of those keep on getting pushed from one 
release
to the next.  If we don't care about diagnostic bugs (which we really 
should
but it seems like we don't), then can we just remove the target 
milestones
for all of those too.

-- Pinski

Re: GCC 4.1 Status Report (2005-08-21)

[Mark Mitchell]

Andrew Pinski wrote:
> 
> On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:
> 
>> (Quite a few of the diagnostic messages
>> stem from the design decision to issue warnings from the
>> optimizers...)
> 
> 
> Only 8 out of 49 at that, though some are very minor as two are just
> complaining wording of the warning.

It was a little snarky of me to throw that in there; I do realize this 
is considered a settled issue.  As you know, it's a pet peeve of mine. 
I still think that until we give up on this approach we're going to see 
strange warning behavior; the price of our quest for better accuracy 
will be less predictability and less consistency from release to release.

> And almost all are uninitialized warnings which are always questionable as there is no way to warn from
> the front-end without flow control.

Most compilers use very simplistic methods for doing these warnings, in 
their front ends.  They still use control flow, but in much simpler 
ways.  The accuracy of the warnings is therefore less than in GCC (in 
that, generally, other compilers warn less often than GCC, and therefore 
detect fewer problems), but the number of false positives is generally 
nearly zero.

Though I don't agree, it's certainly true that the consensus has been to 
try for greater accuracy, by using the optimizers.  I'm not trying to 
upset the apple cart; I was just throwing in a little barb.

> to the next.  If we don't care about diagnostic bugs (which we really 
> should
> but it seems like we don't), then can we just remove the target milestones
> for all of those too.

No, we should not do that.  As you say, we should be trying to fix them. 
  Though, naturally, they're less important, all things equal, to 
wrong-code, rejects-valid, or ice-on-valid bugs.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: GCC 4.1 Status Report (2005-08-21)

[Ian Lance Taylor]

Mark Mitchell <mark@codesourcery.com> writes:

> My first comment is that we had a lot of bugs targeted at 4.1.0 that
> should never have been so targeted.  Please remember that bugs that do
> not effect primary or secondary targets should not have a target
> milestone.  There are several PRs that seem to have had target
> milestones re-added after I removed them before, though it could also
> be that I failed to remove the milestone, even though I added a
> comment to that effect.  PR 17356 is an example of such a PR, though
> in this case it looks like it was Andrew Pinski who removed the target
> milestone.  PR 18190 is another example.  In fact, it almost looks
> like someone went through and methodically re-added target milestones
> to all the PRs for which they had been removed.  If that's the case,
> please stop!

FYI, you can find out when fields like the target milestone were
changed by clicking on the "View Bug Activity" link which is just
under the "Commit" button.

In the case of PR 18190, for example, you removed the target milestone
on 2005-01-19, Andrew set it to 4.1.0 on 2005-03-05 (without adding a
comment), and you removed it again on 2005-08-22.

Ian

Re: GCC 4.1 Status Report (2005-08-21)

[Mark Mitchell]

Ian Lance Taylor wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> 
>>My first comment is that we had a lot of bugs targeted at 4.1.0 that
>>should never have been so targeted.  Please remember that bugs that do
>>not effect primary or secondary targets should not have a target
>>milestone.  There are several PRs that seem to have had target
>>milestones re-added after I removed them before, though it could also
>>be that I failed to remove the milestone, even though I added a
>>comment to that effect.  PR 17356 is an example of such a PR, though
>>in this case it looks like it was Andrew Pinski who removed the target
>>milestone.  PR 18190 is another example.  In fact, it almost looks
>>like someone went through and methodically re-added target milestones
>>to all the PRs for which they had been removed.  If that's the case,
>>please stop!
> 
> 
> FYI, you can find out when fields like the target milestone were
> changed by clicking on the "View Bug Activity" link which is just
> under the "Commit" button.

Aha!  I knew it must be there somewhere.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304