Number of 3.3 hi-pri PRs going up

Number of 3.3 hi-pri PRs going up

[Steven Bosscher]

<plea>

Hi,

Just one week before the planned release of GCC 3.3, the number of
high-priority bugs for 3.3 is going *up* instead of down!

Two weeks ago, there were 72 high-priority PRs, four days ago there were
77, and today there are 80 *high-priority* PRs!  For a handful of those
patches are pending, but most of them are just there waiting to be
picked up and fixed by somebody.  The few people who are fixing and
closing PRs can't keep up with the new PRs coming in every day.

Some stats
- 68 of those 80 PRs are unassigned.
- 46 of those 80 PRs apply to both 3.3 and 3.4 so
  postponing them now will hurt even more later on.
- 8 of those 46 are critical.  This does not even include
  C++ ABI changes from 3.2, such as PR/8964.

Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
causing the bugs have been located.  Unfortunately, hardly any of these
PRs were picked up by by somebody for fixing.

So please help bug-fixing.  This will not only help 3.3 but 3.4 as well
because so many bugs are present on both the release branch and the
trunk.  So even if 3.4 is more interesting to you, locating and/or
fixing bugs for 3.3 will be beneficial to you as well.

</plea>

Greetz
Steven

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> 
> Just one week before the planned release of GCC 3.3, the number of
> high-priority bugs for 3.3 is going *up* instead of down!
> 
> Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> causing the bugs have been located.  Unfortunately, hardly any of these
> PRs were picked up by by somebody for fixing.

Several other people have been helping out with this lately, too.

Fortunately, your statement about hardly any of these bugs being fixed
is not correct; quite a few of them have been fixed, some by the person
who introduced the regression and some by others.  Here's a summary,
which is missing recent reports from other people:

  regressions not yet fixed anywhere (besides the new parser) whose GNATS
  entries identify the patch that introduced the regression
  
  PR     version       reported     submitter    notes
  
  8994   3.2/3.3       2002-12-18   jh
  8964   3.3/3.4       2002-12-23   mark
  8913   3.3           2002-12-12   jason
  8906   3.2/3.3/3.4   2002-12-12   jason
  8828   3.2/3.3       2002-12-24   jakub
  8808   3.2/3.3       2002-12-18   jh
  8730   3.2/3.3       2002-12-24   kenner       intermittent failure
  8634   3.2/3.3       2002-12-23   jh
  8564   3.2/3.3/3.4   2002-12-12   jason
  8555   3.2           2002-12-23   jakub
  8442   3.4           2002-12-14   nathan
  7916   3.2/3.3/3.4   2002-12-20   jh
  7675   3.2/3.3/3.4   2002-12-24   jason
  6387   3.2/3.3       2002-12-14   jakub
  4382   3.2           2002-12-19   rth
  
  
  regressions that exist only on branches whose GNATS entries identify the
  patch that fixed the bug on the mainline
  
  PR     version       reported     submitter    notes
  
  9183   3.2           2003-01-14   mark         gigantic patch
  8582   3.2           2002-12-20   jason
  8205   3.2           2002-12-23   nathan/mark
  8117   3.2           2002-12-13   nathan/mark
  8116   3.2           2002-12-23   nathan
  7247   3.2           2003-01-14   dberlin/dann
  
  
  fixed or otherwise closed after cause was reported; thanks!
  
  PR     reported     fixed        fixer
  
  9342   2003-01-16   2003-01-17   jason
  9258   2003-01-14   2003-02-15   jh
  9167   2003-01-06   2003-01-17   jason
  9165   2003-01-06   2003-01-07   mark
  8849   2002-12-19   2003-01-31   lerdsuwa
  8848   2002-12-12   2003-01-20   rth
  8702   2002-12-16   2002-12-24   nathan
  8602   2003-01-15   2003-02-24   rth
  8572   2002-12-11   2002-12-22   nathan
  8492   2002-12-20   2003-01-22   jh
  7964   2002-12-17   2002-12-24   nathan
  7782   2002-12-11   2003-01-08   jh
  7154   2002-12-17   2003-01-20   rth
  
  9013   2003-01-15   closed       fixed?
  8917   2002-12-16   closed       duplicate of 8913
  7949   2003-01-06   closed       not a bug
  7687   2002-12-20   closed       will not be fixed for branch

> So please help bug-fixing.  This will not only help 3.3 but 3.4 as well
> because so many bugs are present on both the release branch and the
> trunk.  So even if 3.4 is more interesting to you, locating and/or
> fixing bugs for 3.3 will be beneficial to you as well.

I'll run some more regression hunts for regressions in 3.3.  This is now
a background task that takes just a few minutes of work for each PR,
plus a couple of hours of elapsed time, to identify the patch.

Janis

Re: Number of 3.3 hi-pri PRs going up

[Steven Bosscher]

Op vr 21-02-2003, om 18:48 schreef Janis Johnson:
> On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> > 
> > Just one week before the planned release of GCC 3.3, the number of
> > high-priority bugs for 3.3 is going *up* instead of down!
> > 
> > Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> > causing the bugs have been located.  Unfortunately, hardly any of these
> > PRs were picked up by by somebody for fixing.
> 
> Several other people have been helping out with this lately, too.
> 
> Fortunately, your statement about hardly any of these bugs being fixed
> is not correct; quite a few of them have been fixed, some by the person

Hmm it wasn't entirely my own statement, discussed that with some
others.  But it's good to know that the statement is incorrect  :-)

It's still a shame that so many analyzed bugs remain unfixed though.
 
> I'll run some more regression hunts for regressions in 3.3.  This is now
> a background task that takes just a few minutes of work for each PR,
> plus a couple of hours of elapsed time, to identify the patch.

Just curious: What are the begin- and end points of your search?  My
impression so far has been that many many bugs are regressions from
2.95, and Wolfgang's comments confirmed this.  So for such old
regressions it's almost impossible to narrow the problem down to a
single patch, or even a week in which it was applied.

Greetz
Steven

Re: Number of 3.3 hi-pri PRs going up

[Joel Sherrill]

Janis Johnson wrote:
> 
> On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> >
> > Just one week before the planned release of GCC 3.3, the number of
> > high-priority bugs for 3.3 is going *up* instead of down!
> >
> > Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> > causing the bugs have been located.  Unfortunately, hardly any of these
> > PRs were picked up by by somebody for fixing.
> 
> Several other people have been helping out with this lately, too.
> 
> Fortunately, your statement about hardly any of these bugs being fixed
> is not correct; quite a few of them have been fixed, some by the person
> who introduced the regression and some by others.  Here's a summary,
> which is missing recent reports from other people:
> 

I would add a number of embedded targets (m68k, i386, sh, mips64orion,
and hppa1.1) which built in gcc 3.2.2 no longer completely compile:

  + PR9255 - m68k-elf and -rtems don't finish build
             Peter Barada posted a fix to combine.c
  + no PR  - sh-coff, -elf, -rtems, and -rtemself fail
             during install trying to make multilib dirs
  + no PR  - i386-elf and i386-rtems don't build without
             a patch
(http://gcc.gnu.org/ml/gcc-bugs/2003-02/msg00925.html)
  + no PR  - mips64orion-elf and -rtems fail with -march=mips1 not
compatible
             with the selected ABI message
  + no PR  - hppa1.1-proelf fails to build with message
             during configure of newlib that xgcc doesn't make
executables

Those are just the ones where "it used to build and now it doesn't".
A few targets saw no progress fixing problems and some just saw 
ICE's during bootstrap move around.

I haven't filed PRs on the bottom 4 because I just now have a complete
set of cross build logs to look at.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Fri, Feb 21, 2003 at 07:02:30PM +0100, Steven Bosscher wrote:
> Op vr 21-02-2003, om 18:48 schreef Janis Johnson:
>  
> > I'll run some more regression hunts for regressions in 3.3.  This is now
> > a background task that takes just a few minutes of work for each PR,
> > plus a couple of hours of elapsed time, to identify the patch.
> 
> Just curious: What are the begin- and end points of your search?  My
> impression so far has been that many many bugs are regressions from
> 2.95, and Wolfgang's comments confirmed this.  So for such old
> regressions it's almost impossible to narrow the problem down to a
> single patch, or even a week in which it was applied.

Wolfgang and others have, for most of the PRs identified as regressions,
recorded the last release for which the test case worked.  I generally
start with the branch point for the release in which the bug first
shows up and if that's wrong I back up.  If the bug existed on the
mainline when it was reported, then I use the report date as the high
date; otherwise the date when the next release branch was created.

My scripts work just fine with a range of a couple of years.  I use a
local rsync copy of the CVS repository, and if a CVS update fails I
blow away the tree and start over.  I set my searches to go down to
five minutes, and it's actually much quicker to narrow down the range
from a couple of years to a couple of weeks than from a couple of weeks
to the actual patch.

Generally, it doesn't seem to be worthwhile to identify patches that
introduced regressions for things that last worked in 2.95; things have
just changed too much.  Sometimes a bug was introduced by a huge patch,
and in that case it also doesn't help much.  Finding the patch that
fixed a bug on the mainline doesn't always help, either, because
sometimes it was magically fixed by a huge change.

I keep meaning to clean up my scripts and post them (so far I've only
posted the one that provides the outer framework), but I'd be happy to
share them with anyone who would like to try them out.

Janis

Re: Number of 3.3 hi-pri PRs going up

[Michael Matz]

Hi,

On Fri, 21 Feb 2003, Janis Johnson wrote:

>   regressions not yet fixed anywhere (besides the new parser) whose GNATS
>   entries identify the patch that introduced the regression

I don't know, how you came to that list, but I know of at least one other
PR, which causes an ICE (in 3.3 and HEAD) when compiling parts of libboost
(which also affect compilation of lyx).  PR 9524.  I also identified the
introducing patch and made a small analysis of the ICE.


Ciao,
Michael.

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Fri, Feb 21, 2003 at 07:53:38PM +0100, Michael Matz wrote:
> Hi,
> 
> On Fri, 21 Feb 2003, Janis Johnson wrote:
> 
> >   regressions not yet fixed anywhere (besides the new parser) whose GNATS
> >   entries identify the patch that introduced the regression
> 
> I don't know, how you came to that list, but I know of at least one other
> PR, which causes an ICE (in 3.3 and HEAD) when compiling parts of libboost
> (which also affect compilation of lyx).  PR 9524.  I also identified the
> introducing patch and made a small analysis of the ICE.

I stopped keeping it up-to-date about a month ago, and just went through
it today to identify patches that had been fixed recently.  It doesn't
include all PRs for which other people have identified patches.

Janis

Re: Number of 3.3 hi-pri PRs going up

[Michael Matz]

Hi,

On Fri, 21 Feb 2003, Janis Johnson wrote:

> I stopped keeping it up-to-date about a month ago, and just went through
> it today to identify patches that had been fixed recently.  It doesn't
> include all PRs for which other people have identified patches.

Ohh, never mind then ;)


Ciao,
Michael.

Re: Number of 3.3 hi-pri PRs going up

[Toon Moene]

Janis Johnson wrote:

>   fixed or otherwise closed after cause was reported; thanks!
>   
>   PR     reported     fixed        fixer

     9038   ?            2003-02-20   toon

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: Number of 3.3 hi-pri PRs going up

[Jan Hubicka]

> On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> > 
> > Just one week before the planned release of GCC 3.3, the number of
> > high-priority bugs for 3.3 is going *up* instead of down!
> > 
> > Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> > causing the bugs have been located.  Unfortunately, hardly any of these
> > PRs were picked up by by somebody for fixing.
> 
> Several other people have been helping out with this lately, too.
> 
> Fortunately, your statement about hardly any of these bugs being fixed
> is not correct; quite a few of them have been fixed, some by the person
> who introduced the regression and some by others.  Here's a summary,
> which is missing recent reports from other people:
> 
>   regressions not yet fixed anywhere (besides the new parser) whose GNATS
>   entries identify the patch that introduced the regression
>   
>   PR     version       reported     submitter    notes
>   
>   8994   3.2/3.3       2002-12-18   jh
I've moved this one into 3.2 only regression.  It is fixed on 3.3 branch
by the regmove cost patches.  Should we try to backport it into 3.2?
>   8964   3.3/3.4       2002-12-23   mark
>   8913   3.3           2002-12-12   jason
>   8906   3.2/3.3/3.4   2002-12-12   jason
>   8828   3.2/3.3       2002-12-24   jakub
>   8808   3.2/3.3       2002-12-18   jh

This is old problem with using registers in ASM statements that are not
possible to use in given context.  I would suggest to suspend this bug
as same crash can be reproduced with different registers too.
I am not sure about proper fix here.  Richard suggested adding new mask
of registers that are available for use, but this would need to work
together with modes and so on, so it is somewhat crazy.
I will try to do something.

>   8730   3.2/3.3       2002-12-24   kenner       intermittent failure
>   8634   3.2/3.3       2002-12-23   jh

Zdene has patch for this one.  Quite nasty bug in addressof ellimination

>   8564   3.2/3.3/3.4   2002-12-12   jason
>   8555   3.2           2002-12-23   jakub
>   8442   3.4           2002-12-14   nathan
>   7916   3.2/3.3/3.4   2002-12-20   jh

This is another latent bug with ASM statements.  The 'l' statement is
unrecognized stmt decides to put memory statement into it.  Later this
fails in virtual registers ellimination.
Not sure what to do about it - I can prohibit virtual registers in the
memory statements but I believe the whole purpose of the hackery is to
allow specially formed memory expressions here.  Otherwise I can simply
prohibit memory reference when unknown constraint is hit.
Not sure how this is supposed to work at all.

Honza

Re: Number of 3.3 hi-pri PRs going up

[Michael S. Zick]

On Friday 21 February 2003 12:39 pm, Janis Johnson wrote:
>
> My scripts work just fine with a range of a couple of years.  I use a
> local rsync copy of the CVS repository, and if a CVS update fails I
> blow away the tree and start over.  
>
Getting that initial rsync copy is the real killer here.

Is it possible to burn a copy of the CVS repository on CD's once
every month (or two, or three, or...)?
Then post where the CD-ROM's can be purchased.
Perhaps one of the GCC based vendors could do that for
the project as a step towards getting more regression hunting /
bug fixing underway.

Mike

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> On Friday 21 February 2003 12:39 pm, Janis Johnson wrote:
> >
> > My scripts work just fine with a range of a couple of years.  I use a
> > local rsync copy of the CVS repository, and if a CVS update fails I
> > blow away the tree and start over.  
> >
> Getting that initial rsync copy is the real killer here.
> 
> Is it possible to burn a copy of the CVS repository on CD's once
> every month (or two, or three, or...)?
> Then post where the CD-ROM's can be purchased.
> Perhaps one of the GCC based vendors could do that for
> the project as a step towards getting more regression hunting /
> bug fixing underway.

I doubt that there would be much of a demand for those CDs, but perhaps
some kind person will offer to make you one so you can help hunt for
regressions; unfortunately I can't do that.

Janis

Re: Number of 3.3 hi-pri PRs going up

[Phil Edwards]

On Tue, Feb 25, 2003 at 09:48:10AM -0800, Janis Johnson wrote:
> On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > >
> > Getting that initial rsync copy is the real killer here.
> > 
> > Is it possible to burn a copy of the CVS repository on CD's once
> > every month (or two, or three, or...)?
> > Then post where the CD-ROM's can be purchased.
> > Perhaps one of the GCC based vendors could do that for
> > the project as a step towards getting more regression hunting /
> > bug fixing underway.
> 
> I doubt that there would be much of a demand for those CDs,

Seconded.

> > Then post where the CD-ROM's can be purchased.
> > Perhaps one of the GCC based vendors could do that for
> > the project as a step towards getting more regression hunting /
> > bug fixing underway.

Shoot, I'd do it for free if I had a CD burner.  Blanks are actually
cheaper than paper around here, and postage (for the few people wanting
a CD) would cost less than what I spend on caffeine in a typical day.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Number of 3.3 hi-pri PRs going up

[Steven Bosscher]

Op di 25-02-2003, om 18:47 schreef Phil Edwards:
> On Tue, Feb 25, 2003 at 09:48:10AM -0800, Janis Johnson wrote:
> > On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > > >
> > > Getting that initial rsync copy is the real killer here.
> > > 
> > > Is it possible to burn a copy of the CVS repository on CD's once
> > > every month (or two, or three, or...)?
> > > Then post where the CD-ROM's can be purchased.
> > > Perhaps one of the GCC based vendors could do that for
> > > the project as a step towards getting more regression hunting /
> > > bug fixing underway.
> > 
> > I doubt that there would be much of a demand for those CDs,
> 
> Seconded.

Yeah, just a "burn-on-demand" availability should be enough.

> > > Then post where the CD-ROM's can be purchased.
> > > Perhaps one of the GCC based vendors could do that for
> > > the project as a step towards getting more regression hunting /
> > > bug fixing underway.
> 
> Shoot, I'd do it for free if I had a CD burner.

The current rsync repository is almost 1GB (it was +/- 950 MB on
December 2, 2002, and we have a new branch now and a new C++ parser), so
unless you can compress it to about 50% of that, you're not even going
to be able to burn it on a single CD.

>  Blanks are actually
> cheaper than paper around here, and postage (for the few people wanting
> a CD) would cost less than what I spend on caffeine in a typical day.

You should stop drinking redbull then :-)

Greetz
Steven

Re: Number of 3.3 hi-pri PRs going up

[Joel Sherrill]

Steven Bosscher wrote:
> 
> Op di 25-02-2003, om 18:47 schreef Phil Edwards:
> > On Tue, Feb 25, 2003 at 09:48:10AM -0800, Janis Johnson wrote:
> > > On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > > > >
> > > > Getting that initial rsync copy is the real killer here.
> > > >
> > > > Is it possible to burn a copy of the CVS repository on CD's once
> > > > every month (or two, or three, or...)?
> > > > Then post where the CD-ROM's can be purchased.
> > > > Perhaps one of the GCC based vendors could do that for
> > > > the project as a step towards getting more regression hunting /
> > > > bug fixing underway.
> > >
> > > I doubt that there would be much of a demand for those CDs,
> >
> > Seconded.
> 
> Yeah, just a "burn-on-demand" availability should be enough.

Would it be sufficient for a cron job to make an tarball of the
CVS repository available for download say once a week? 

Was the "mail a CD" offer just to avoid the bandwidth issue?

> > > > Then post where the CD-ROM's can be purchased.
> > > > Perhaps one of the GCC based vendors could do that for
> > > > the project as a step towards getting more regression hunting /
> > > > bug fixing underway.
> >
> > Shoot, I'd do it for free if I had a CD burner.
> 
> The current rsync repository is almost 1GB (it was +/- 950 MB on
> December 2, 2002, and we have a new branch now and a new C++ parser), so
> unless you can compress it to about 50% of that, you're not even going
> to be able to burn it on a single CD.

bzip2 is usually pretty good at compressing things so if you could
get 2-3x compression, it should fit.

> >  Blanks are actually
> > cheaper than paper around here, and postage (for the few people wanting
> > a CD) would cost less than what I spend on caffeine in a typical day.
> 
> You should stop drinking redbull then :-)
>
> Greetz
> Steven

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Number of 3.3 hi-pri PRs going up

[Phil Edwards]

On Tue, Feb 25, 2003 at 12:24:58PM -0600, Joel Sherrill wrote:
> Steven Bosscher wrote:
> > Op di 25-02-2003, om 18:47 schreef Phil Edwards:
> > 
> > Yeah, just a "burn-on-demand" availability should be enough.
> 
> Would it be sufficient for a cron job to make an tarball of the
> CVS repository available for download say once a week? 
> 
> Was the "mail a CD" offer just to avoid the bandwidth issue?

I think so.  Once the repo is initially downloaded/installed/whatever, rsync
does a most excellent job of keeping the repo up to to date with minimal
bandwidth usage.  So a snailmailed CD would truly be a one-time setup.

Heck, we could just burn one copy and then each person mails it to
the next.  :-)


> > The current rsync repository is almost 1GB (it was +/- 950 MB on
> > December 2, 2002, and we have a new branch now and a new C++ parser), so
> > unless you can compress it to about 50% of that, you're not even going
> > to be able to burn it on a single CD.
> 
> bzip2 is usually pretty good at compressing things so if you could
> get 2-3x compression, it should fit.

It's nearly all text.  Last time I had to do that to the repo I got superb
compression ratios.

Besides, what with filename conventions vs burning software, it'd probably
be most portable to create a single repo.tar.bz2 file, and then burn that
to the disc rather than trying to mirror the structure.


> > You should stop drinking redbull then :-)

Bite your tongue, that stuff would kill a horse at fifty paces.  Coffee!  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Tue, Feb 25, 2003 at 12:24:58PM -0600, Joel Sherrill wrote:
> Steven Bosscher wrote:
> > Op di 25-02-2003, om 18:47 schreef Phil Edwards:
> > > On Tue, Feb 25, 2003 at 09:48:10AM -0800, Janis Johnson wrote:
> > > > On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > > > > >
> > > > > Getting that initial rsync copy is the real killer here.
> > > > >
> > > > > Is it possible to burn a copy of the CVS repository on CD's once
> > > > > every month (or two, or three, or...)?
> > > > > Then post where the CD-ROM's can be purchased.
> > > > > Perhaps one of the GCC based vendors could do that for
> > > > > the project as a step towards getting more regression hunting /
> > > > > bug fixing underway.
> > > >
> > > > I doubt that there would be much of a demand for those CDs,
> > >
> > > Seconded.
> > 
> > Yeah, just a "burn-on-demand" availability should be enough.
> 
> Would it be sufficient for a cron job to make an tarball of the
> CVS repository available for download say once a week? 
> 
> Was the "mail a CD" offer just to avoid the bandwidth issue?
> 
> > The current rsync repository is almost 1GB (it was +/- 950 MB on
> > December 2, 2002, and we have a new branch now and a new C++ parser), so
> > unless you can compress it to about 50% of that, you're not even going
> > to be able to burn it on a single CD.
> 
> bzip2 is usually pretty good at compressing things so if you could
> get 2-3x compression, it should fit.

See the "Short Cuts" section of http://gcc.gnu.org/bugs/reghunt.html for
hints about chopping down an rsync repository for use in regression
hunts.

Janis

Re: Number of 3.3 hi-pri PRs going up

[Aaron Lehmann]

On Tue, Feb 25, 2003 at 07:14:23PM +0100, Steven Bosscher wrote:
> The current rsync repository is almost 1GB (it was +/- 950 MB on
> December 2, 2002, and we have a new branch now and a new C++ parser), so
> unless you can compress it to about 50% of that, you're not even going
> to be able to burn it on a single CD.

It compresses to much smaller than the size of a CD.

Re: Number of 3.3 hi-pri PRs going up

[Steven Bosscher]

Op di 25-02-2003, om 20:43 schreef Aaron Lehmann:
> On Tue, Feb 25, 2003 at 07:14:23PM +0100, Steven Bosscher wrote:
> > The current rsync repository is almost 1GB (it was +/- 950 MB on
> > December 2, 2002, and we have a new branch now and a new C++ parser), so
> > unless you can compress it to about 50% of that, you're not even going
> > to be able to burn it on a single CD.
> 
> It compresses to much smaller than the size of a CD.

Then is it a good idea to make a compressed repository available for
download every week (or month), like Joel suggested?  Even a trimmed
down repro, such as the one you get if you follow Janis' instructions
from http://gcc.gnu.org/bugs/reghunt.html, would be nice.

Greetz
Steven

Re: Number of 3.3 hi-pri PRs going up

[Aaron Lehmann]

On Tue, Feb 25, 2003 at 08:58:28PM +0100, Steven Bosscher wrote:
> Then is it a good idea to make a compressed repository available for
> download every week (or month), like Joel suggested?  Even a trimmed
> down repro, such as the one you get if you follow Janis' instructions
> from http://gcc.gnu.org/bugs/reghunt.html, would be nice.

People can just rsync the repository themselves, using much less
bandwidth. rsync can compress data in transit using -z.

Re: Number of 3.3 hi-pri PRs going up

[Michael S. Zick]

On Tuesday 25 February 2003 11:48 am, Janis Johnson wrote:
> On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > On Friday 21 February 2003 12:39 pm, Janis Johnson wrote:
> > > My scripts work just fine with a range of a couple of years.  I use a
> > > local rsync copy of the CVS repository, and if a CVS update fails I
> > > blow away the tree and start over.
> >
> > Getting that initial rsync copy is the real killer here.
> >
> > Is it possible to burn a copy of the CVS repository on CD's once
> > every month (or two, or three, or...)?
> > Then post where the CD-ROM's can be purchased.
> > Perhaps one of the GCC based vendors could do that for
> > the project as a step towards getting more regression hunting /
> > bug fixing underway.
>
> I doubt that there would be much of a demand for those CDs, but perhaps
> some kind person will offer to make you one so you can help hunt for
> regressions; unfortunately I can't do that.
>
> Janis
Understood.

If the demand is very low - perhaps I could do that for anyone interested.
The people interested would ones (such as myself) that have a low-speed
Inet connection and need a way to get the initial copy.

My plan would be:
1) Get a rsync copy working / staying in sync.
2) Do a "monthly burn" of the data - keep a recent images on disk
3) Announce somewhere (gcc announce?) how to contact me for
a copy (I think it is growing to 2-cds worth by now).
4) If Janis could get all of his regression hunting scripts into contrib,
then everything would be on the cds.
5) If demand ever gets to be more than I can handle, then this plan
can be reconsidered.

How does that sound?
Mike

Re: Number of 3.3 hi-pri PRs going up

[Michael S. Zick]

On Tuesday 25 February 2003 12:24 pm, Joel Sherrill wrote:
> Steven Bosscher wrote:
> > Op di 25-02-2003, om 18:47 schreef Phil Edwards:
> > > On Tue, Feb 25, 2003 at 09:48:10AM -0800, Janis Johnson wrote:
> > > > On Sat, Feb 22, 2003 at 08:56:53AM -0600, Michael S. Zick wrote:
> > > > > Getting that initial rsync copy is the real killer here.
> > > > >
> > > > > Is it possible to burn a copy of the CVS repository on CD's once
> > > > > every month (or two, or three, or...)?
> > > > > Then post where the CD-ROM's can be purchased.
> > > > > Perhaps one of the GCC based vendors could do that for
> > > > > the project as a step towards getting more regression hunting /
> > > > > bug fixing underway.
> > > >
> > > > I doubt that there would be much of a demand for those CDs,
> > >
> > > Seconded.
> >
> > Yeah, just a "burn-on-demand" availability should be enough.
>
> Would it be sufficient for a cron job to make an tarball of the
> CVS repository available for download say once a week?
>
> Was the "mail a CD" offer just to avoid the bandwidth issue?
>
Yes.  The download time of the initial rsync copy.
Have you ever computed the bandwidth of a 747 packed with
cds?

Mike

Re: Number of 3.3 hi-pri PRs going up

[Michael S. Zick]

On Tuesday 25 February 2003 01:58 pm, Steven Bosscher wrote:
> Op di 25-02-2003, om 20:43 schreef Aaron Lehmann:
> > On Tue, Feb 25, 2003 at 07:14:23PM +0100, Steven Bosscher wrote:
> > > The current rsync repository is almost 1GB (it was +/- 950 MB on
> > > December 2, 2002, and we have a new branch now and a new C++ parser),
> > > so unless you can compress it to about 50% of that, you're not even
> > > going to be able to burn it on a single CD.
> >
> > It compresses to much smaller than the size of a CD.
>
> Then is it a good idea to make a compressed repository available for
> download every week (or month), like Joel suggested?  Even a trimmed
> down repro, such as the one you get if you follow Janis' instructions
> from http://gcc.gnu.org/bugs/reghunt.html, would be nice.
>
> Greetz
> Steven
My intent was to encourage regression hunting beyond the C and C++
subsets.  Therefore the "complete copy".
Hopefully, by folks with a "strange" triplet that wouldn't be duplicating
work already being done.

Mike
PS: Yes, I know about bzip2 and tar.

Re: Number of 3.3 hi-pri PRs going up

[Janis Johnson]

On Tue, Feb 25, 2003 at 08:36:30PM -0600, Michael S. Zick wrote:
> 4) If Janis could get all of his regression hunting scripts into contrib,
                               ^^^ her (as in Janis Joplin)
> then everything would be on the cds.

I've asked about putting them into contrib, and Phil Edwards has asked
a couple of times to put them into contrib, but no one has said who
needs to give permission to do that.  The main script is available in
the mailing list archives, with a link from
html://gcc.gnu.org/bugs/reghunt.html.  The others are things that
people would probably want to replace with their own anyway, but it
would be useful to have examples available.

Ms. Janis

Repository CDs (Re: Number of 3.3 hi-pri PRs going up)

[Michael S. Zick]

On Wednesday 26 February 2003 11:17 am, Janis Johnson wrote:
> On Tue, Feb 25, 2003 at 08:36:30PM -0600, Michael S. Zick wrote:
> > 4) If Janis could get all of his regression hunting scripts into contrib,
>
>                                ^^^ her (as in Janis Joplin)
>
> > then everything would be on the cds.
>
> I've asked about putting them into contrib, and Phil Edwards has asked
> a couple of times to put them into contrib, but no one has said who
> needs to give permission to do that.  

Perhaps this is one more good reason for someone to OK that.

> The main script is available in
> the mailing list archives, with a link from
> html://gcc.gnu.org/bugs/reghunt.html.  

It would probably be good idea if I included the relevant pages on the 
CD (in addition to the copies in the CVS repository copy).

> The others are things that
> people would probably want to replace with their own anyway, but it
> would be useful to have examples available.

Examples are always a good thing to have.

>
> Ms. Janis
Sorry about the inadvertent gender change.

Until somebody posts a "We Do That Already" reply, I'll continue
with setting up to do this.  Not sure how long it will take to get
set-up, I'll post a note when copies are available.

Note: Send CD offers (I sure could use one now) and CD
requests to mszick at morethan dot org.  I'll notice those posts.

Mike

Re: Number of 3.3 hi-pri PRs going up

[Gerald Pfeifer]

On Wed, 26 Feb 2003, Janis Johnson wrote:
>> 4) If Janis could get all of his regression hunting scripts into contrib,
>                               ^^^ her (as in Janis Joplin)
>> then everything would be on the cds.
> I've asked about putting them into contrib, and Phil Edwards has asked
> a couple of times to put them into contrib, but no one has said who
> needs to give permission to do that.  The main script is available in
> the mailing list archives, with a link from
> html://gcc.gnu.org/bugs/reghunt.html.  The others are things that
> people would probably want to replace with their own anyway, but it
> would be useful to have examples available.

Okay, let's break this deadlock.

Approval by Phil, you, and me really should be sufficient for putting
something into contrib, so I suggest you repost your scripts to
gcc-patches and commit them after 10 days unless someone seriously
complains.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Number of 3.3 hi-pri PRs going up

[Steven Bosscher]

Op vr 21-02-2003, om 18:55 schreef Robert Dewar:
> 
> 
> On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> > 
> > Just one week before the planned release of GCC 3.3, the number of
> > high-priority bugs for 3.3 is going *up* instead of down!
> > 
> > Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> > causing the bugs have been located.  Unfortunately, hardly any of these
> > PRs were picked up by by somebody for fixing.
> 
> Actually you don't mean that the number of bugs is going up, you mean that
> the number of *known* bugs is going up.

Right, s/bugs/PRs/g

I mean that a number of bugs, that have been ignored since they were
submitted, are being re-discovered by people who took the time to look
at all the bugs in the database.

> There is nothing special about a day on which you know of no high priority bugs,
> it does not mean that something is more reliable on that day than on the day before
> when you fixed one bug (but perhaps introduced another that you don't know about)
> or the next day when you discovered two more bugs that had been there for ever.

I disagree.  There *is* something special about a day on which you see
the number of high priority bugs go up.  It means that there are
literaly dozens of bug reports that have simply been ignored since they
were reported.
(Right now, if a bug comes in, it's analyzed almost immediately.  Sadly,
it wasn't always like that...)

You're right that this doesn't make the compiler less reliable all of a
sudden, because in part those "new" high-priority PRs have been there
for months, and they only are high priority now because somebody
analysed them.

But, the point is not the reliability of the compiler from one day to
the next, but from one *release* to the next. Now look at the number of
regressions from 3.2 on the 3.3 branch...

The fact that one bug fix may cause new bugs is even more worrying
because when so many bug fixes go in just before a release, you may end
up with a compiler that used to work in all the pre-releases and is
suddenly broken in the actual release.  Has that ever happened with GCC?

> I always find that at the time of a release, people get into a mode of being
> upset if there are high priority known bugs, and of course it is great to squash
> all the bugs you can, but realistically the system has a large number of bugs that
> you don't know about, and for a user it matters little whether a bug is known
> or not known (actually it is somewhat better if it is known, because then perhaps
> it can be avoided).

The only reason why these bugs are known now is because some people took
a lot of time to analyse a four digit number of bugs.  Again, many bugs
already were in GNATS, but they were never picked up.

I wouldn't consider 3.3 "better" than a previous release because we now
know about all the regressions from <your favorite GCC version here>.

Anyway, don't get me wrong: I know we'll never see all bugs being
closed, and we'll always have new regressions.  I just think this whole
situation is unfortunate because GCC is already getting a lot of
criticism about its relative slowness, and if the project would release
3.3 with so many known regressions, it probably just means more bad
publicity and fewer reasons for people to start using it.

Greetz
Steven

Re: Number of 3.3 hi-pri PRs going up

[Robert Dewar]

On Fri, Feb 21, 2003 at 01:20:03PM +0100, Steven Bosscher wrote:
> 
> Just one week before the planned release of GCC 3.3, the number of
> high-priority bugs for 3.3 is going *up* instead of down!
> 
> Mostly thanks to Wolfgang and Janis, for quite a few PRs the patches
> causing the bugs have been located.  Unfortunately, hardly any of these
> PRs were picked up by by somebody for fixing.

Actually you don't mean that the number of bugs is going up, you mean that
the number of *known* bugs is going up.

There is nothing special about a day on which you know of no high priority bugs,
it does not mean that something is more reliable on that day than on the day before
when you fixed one bug (but perhaps introduced another that you don't know about)
or the next day when you discovered two more bugs that had been there for ever.

I always find that at the time of a release, people get into a mode of being
upset if there are high priority known bugs, and of course it is great to squash
all the bugs you can, but realistically the system has a large number of bugs that
you don't know about, and for a user it matters little whether a bug is known
or not known (actually it is somewhat better if it is known, because then perhaps
it can be avoided).

Re: Number of 3.3 hi-pri PRs going up

[Wolfgang Bangerth]

> Two weeks ago, there were 72 high-priority PRs, four days ago there were
> 77, and today there are 80 *high-priority* PRs!  For a handful of those
> patches are pending, but most of them are just there waiting to be
> picked up and fixed by somebody.

Being one of the seemingly few with a good overview of what is there in 
GNATS, just a few thoughts:
- I believe that these numbers not really represent a setback in quality 
  in gcc. They more closely reflect that the bug database has been sitting
  around idly for a long time, and that we uncovered regressions from long
  ago that nobody knew about since nobody cared to look at the respective
  PRs. However, it is my firm belief that these regressions should be 
  fixed. We did not do so in the previous releases pretending not to know
  about them. Fixing them should significantly improve the quality of gcc.

- I think that we presently have a rather good overview of the state of 
  gcc. At least for the C++ part, it is fair to say that the number of
  regressions listed in gnats in un-analyzed reports is very small. I 
  think we have looked at almost every report that is in there, checked 
  it, and checked most of them against the new parser. So if the number of
  regressions is growing, then only due to newly incoming reports. 
  Turnaround time for new C++ reports is presently below one day, on
  average, I'd say.

- In a general perspective: the number of hi-pri regressions constitutes a
  non-vanishing fraction of the total number of open PRs (for C++: 80 out
  of 480). If we could fix them, we'd already be a significant step
  towards reducing the total number of unfixed bugs.

[Port maintainers:]
- The state of reports in the "bootstrap" and "target" categories is
  probably best described by "neglected". Since not many people can test
  them, it really requires more attention by the port maintainers. The 
  majority of our 1800 or so unfixed reports are in these categories, and
  many of them are in "open" state since their filing -- often two years
  or more ago. I have tried to make an effort to indicate in the synopsis
  of many of them for which target they are, but that doesn't seem to
  incite maintainers to look at them :-( If nobody cares about these
  reports, we could just as well delete them, since the bug database is
  worthless then.

Given our present perspective on the database, I'd say that at least for 
the C/C++/libstdc++/optimization part, the number of open reports is 
actually not so vast. I would think that if people started to really 
concentrate on fixing bugs, a significant amount (say, half of them) could 
actually closed within one or two months. Doing so would bring us into a 
much better position where it is simpler to justify doing the fancy stuff 
(new optimizations, etc) rather than the boring bug fixing. But then I 
know that this will not happen, unfortunately...

W.

-------------------------------------------------------------------------
Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                              www: http://www.ticam.utexas.edu/~bangerth/