Re: Volunteer for bug summaries?

[Jan-Benedict Glaw]

On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Is there a volunteer who would like to help prepare a regular list of
> P3-and-higher PRs, together with -- where known -- the name of the
> person responsible for the checkin which caused the regression?  Or, is
> this something that could be automated through Bugzilla, perhaps by
> adding a pointer to the SVN revision at which the regression was introduced?

For a start, isn't there enough computation power on the testing
cluster to build all and any revisions of binutils+gcc to run the test
suite?  Shouldn't be hard to implement and would be helpful.  I'd
volunteer to prepare the setup, if somebody supplies the CPU cycles.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:   Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second  :   Langsam möchte ich mal wieder weiterträumen können.


signature.asc
Description: Digital signature

Re: Volunteer for bug summaries?

[Manuel López-Ibáñez]

On 22/05/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:

On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Is there a volunteer who would like to help prepare a regular list of
> P3-and-higher PRs, together with -- where known -- the name of the
> person responsible for the checkin which caused the regression?  Or, is
> this something that could be automated through Bugzilla, perhaps by
> adding a pointer to the SVN revision at which the regression was introduced?

For a start, isn't there enough computation power on the testing
cluster to build all and any revisions of binutils+gcc to run the test
suite?  Shouldn't be hard to implement and would be helpful.  I'd
volunteer to prepare the setup, if somebody supplies the CPU cycles.



I am not sure what you mean exactly. Running the testsuite is not the
issue (it must be run for every patch). The discussion is about having
a PR with a testcase, then identifying at which revision that testcase
started to fail, then identifying who committed that revision.

Janis has some scripts to do regression hunting. However, it is not
fully automatic. For one reason or another, some revisions fail to
built. When that happens, you need to mark that revision as ignored
and restart the regression hunt. Perhaps you can modify the scripts to
handle such situation. Maybe it should also contain a list of "bad"
revisions. Apart from this, the scripts are very powerful and
intuitive (although some docs would also help everybody).

On the other hand, setting up the regression hunt is not automatic
either but with some practice, documentation and fine-tuning of the
scripts, it can be made fairly trivial.

Cheers,

Manuel.

Re: Volunteer for bug summaries?

[Jan-Benedict Glaw]

On Tue, 2007-05-22 08:50:59 +0100, Manuel López-Ibáñez <[EMAIL PROTECTED]> 
wrote:
> On 22/05/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell <[EMAIL PROTECTED]> 
> > wrote:
> > > Is there a volunteer who would like to help prepare a regular list of
> > > P3-and-higher PRs, together with -- where known -- the name of the
> > > person responsible for the checkin which caused the regression?  Or, is
> > > this something that could be automated through Bugzilla, perhaps by
> > > adding a pointer to the SVN revision at which the regression was 
> > introduced?
> >
> > For a start, isn't there enough computation power on the testing
> > cluster to build all and any revisions of binutils+gcc to run the test
> > suite?  Shouldn't be hard to implement and would be helpful.  I'd
> > volunteer to prepare the setup, if somebody supplies the CPU cycles.
> 
> I am not sure what you mean exactly. Running the testsuite is not the
> issue (it must be run for every patch). The discussion is about having
> a PR with a testcase, then identifying at which revision that testcase
> started to fail, then identifying who committed that revision.

Whee...  You're right, I got that wrong. Doesn't change anything about
scripting work, though. :)

> Janis has some scripts to do regression hunting. However, it is not
> fully automatic. For one reason or another, some revisions fail to
> built. When that happens, you need to mark that revision as ignored
> and restart the regression hunt. Perhaps you can modify the scripts to
> handle such situation. Maybe it should also contain a list of "bad"
> revisions. Apart from this, the scripts are very powerful and
> intuitive (although some docs would also help everybody).
> 
> On the other hand, setting up the regression hunt is not automatic
> either but with some practice, documentation and fine-tuning of the
> scripts, it can be made fairly trivial.

Alas, it sounds like an interesting project and I'd help trying to
automate it as far as possible.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:http://catb.org/~esr/faqs/smart-questions.html
the second  :


signature.asc
Description: Digital signature

Re: A reload inheritance bug

[Bernd Schmidt]

Mark Shinwell wrote:
> The relevant RTL instructions before reload are as follows.  These
> correspond to points A, B and C respectively in my previous email.

I must admit I'm still stumbling in the dark a bit - this would be so
much easier to digest with a testcase.

The question I'm trying to answer is - why does this happen in this
testcase only, what makes it special?

> insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275))
> 
> insn 5291 (set (reg:DF 4078])
>   (mem/s:DF (plus:SI (reg/f:SI 3275) (reg:SI 3812
>   REG_DEAD 3275
> 
> insn 5314 (set (reg:DF 4096)
>   (mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084

> After reload we end up with the following.  I've added dividers to show
> the correspondence with the insns above.
> 
> insn 5301 (set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp) (const_int 12)))
>(reg/f:SI 9 r9 [3275]))
> ---
> insn 6675 (set (reg:SI 9 r9)
>(plus:SI (reg/f:SI 9 r9 [3275]) (reg:SI 10 sl [3812])))
> 
> insn 5291 (set (reg:DF 75 s12 [4078])
>(mem/s:DF (reg:SI 9 r9)))
> ---
> insn 6680 (set (reg:SI 1 r1) (const_int 4928))
> 
> insn 6681 (set (reg:SI 1 r1)
>(plus:SI (reg/f:SI 9 r9 [3275]) (reg:SI 1 r1)))
> 
> insn 5314 (set (reg:DF 75 s12 [4096])
>(mem/s:DF (reg:SI 1 r1)))
> 
> We see here how pseudo 3275 was allocated to r9 and pseudo 4082 was
> spilled to the stack.  At insn 5291, r9 has been allocated [*] as the
> reload register since pseudo 3275 dies in that instruction; at insn
> 5314 we see the then-incorrect use of r9 (in instruction 6681)
> for the value of pseudo 4082.  Note also how the dump shows that the
> compiler thinks r9 still holds the value of pseudo 3275 at insn 6681.

Presumably this is one thing that is mildly unusual - R9 being chosen in
find_reloads already.  This wouldn't happen later, since it's in
reg_used_in_insn and therefore disallowed.

Still, assume a similar sequence

insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275))

insn 5291 (set (reg:DF 4078])
   (unspec:DF (mem/s:DF (plus:SI (reg/f:SI 3275)
 (reg:SI 3812)))
  (reg:SI 3275)))
  REG_DEAD 3275



insn 5314 (set (reg:DF 4096)
  (mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084

Here, we wouldn't use R9 as reload register in 5291, but could use it
subsequently (as it's no longer live holding 3275) for another input
reload.  Then we'd run into the same problem in insn 5314.

Still not sure why either case would be so unusual that we haven't seen
this before.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: I don't understand some of gcc-4.1-20070514, a patch here.

[Bernd Jendrissek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, May 21, 2007 at 11:47:15PM +0200, J.C. Pizarro wrote:
> http://en.wikipedia.org/wiki/Brainfuck

If you're going to insult the contributors to GCC's code base by
comparing the code they work on to bf, then I think you should write
better English than the following:

> I'm saying is that you do not develop the source code directly to machine
> and distantly to the human natural language.
> 
> The lecture of the legible source code is more important than brainfucking
> the source code for maximum speed.

Let the one that is without sin cast the first stone, hey?  I don't
understand what you mean by "distantly" or "lecture", for example.

> I hate "if (ptr) { ... }" /* <- It's b-r-a-i-n-f-u-c-k-e-d source code! */
> I love "if (ptr != NULL) { ... }"

Personally, I find the former idiom more readable.  It doesn't require
me to visually and cognitively distinguish between "==" and "!=".
That's my personal choice, but I won't die, and nor will I hurl insults
if other people want to choose differently.

http://c2.com/cgi/wiki?PersonalChoiceElevatedToMoralImperative

If you really want to contribute to the Free Software movement, then my
personal advice to you is to show a bit more respect to the people who
make it happen.  A compiler collection like GCC is a mature, large and
complicated piece of software; a lot of work has gone into making it and
there are some very very clever people working on it - certainly
cleverer than you or I.  You should show some humility for what has come
and gone before you: everything you see in the code base has a reason
for being there, and if you can't tell what that reason is, it means YOU
haven't thought about it hard enough.

- -- 
Seen in comp.lang.c:
> cody wrote:
>> The problem is that i believe that my assertions are correct.
> Yes, that is a problem.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGUtBHwyMv24BBd/gRAno7AJ9VoHb2PoEpEeB8dvg8vy5pzhN32wCgkAnK
N/XuV3jJ+YQZLIQusJTzs0o=
=46X2
-END PGP SIGNATURE-

[4.2.0] Can't bootstrap for cywin: bootstrap comparison failure in ./ada/exp_aggr.o differs

[Christian Joensson]

As I posted on http://gcc.gnu.org/ml/gcc/2007-05/msg00058.html, I
still have this problem for the released 4.2.0.

--
Cheers,

/ChJ

Re: Volunteer for bug summaries?

[François-Xavier Coudert]

Hi,

When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?

In my opinion, all regressions should always be assigned to someone,
at all times. Either to the identified guilty party, or to a volunteer
or maintainer of that field, who is then responsible for identifying
the guilty party, or finding someone who accepts to do it. This sounds
like a reasonable way of making sure some regressions don't get
forgotten, doesn't it?

FX

Re: Volunteer for bug summaries?

[Richard Guenther]

On 5/22/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:

Hi,

When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?

In my opinion, all regressions should always be assigned to someone,
at all times. Either to the identified guilty party, or to a volunteer
or maintainer of that field, who is then responsible for identifying
the guilty party, or finding someone who accepts to do it. This sounds
like a reasonable way of making sure some regressions don't get
forgotten, doesn't it?


CCing the person who caused the regression is more appropriate.  Assigning
bugs to them detracts others from fixing the bug.

Richard.

gcc-current: badly worded warning?

[Eyal Lebedinsky]

I see two kinds of warnings:
warning: logical '||' with non-zero constant will always evaluate as 
true
warning: logical '&&' with non-zero constant will always evaluate as 
true

The first statement is true, the second false. It can say (if the case is such)
warning: logical '&&' with zero constant will always evaluate as false
and even warn of
warning: logical '&&' with non-zero constant will have no effect

Actually, the statement leading to the '&&' warning has both logical operators.
Warning of the 'const ||' would actually be valid but none was issued.

#define SSA_ERRMSG_CHECK_BADRC  1   /* force error logging */
...
if (rc > 0 && (SSA_ERRMSG_CHECK_BADRC || (SSA_LOG_ERRORS & flags)))

and I would expect these two warnings for this statement:
warning: logical '||' with non-zero constant will always evaluate as 
true
warning: logical '&&' with non-zero constant will have no effect

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat

Re: Volunteer for bug summaries?

[François-Xavier Coudert]

CCing the person who caused the regression is more appropriate.  Assigning
bugs to them detracts others from fixing the bug.


We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a few more mails (and some people
don't even read their bugzilla mail).

Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
that is triggered on the GCC testsuite, it has been known for more
than 2 months, Janis kindly did a reghunt a month ago to attribute it,
the patch author was added in the CC list. Since then, nothing
happened.

I'm taking this example because I was remembered about it by a mail on
the fortran list, but it has nothing specific, there are scores of
these kind out there. I think assigning regressions to people who
introduced them is only fair, after all, they are supposed to take
care of it or find someone else to do it!

FX

Re: Volunteer for bug summaries?

[Joe Buck]

On Tue, May 22, 2007 at 06:13:58PM +0200, François-Xavier Coudert wrote:
> >CCing the person who caused the regression is more appropriate.  Assigning
> >bugs to them detracts others from fixing the bug.
> 
> We already do that, and in lots of cases it doesn't work. CCing is not
> coercive enough, you only receive a few more mails (and some people
> don't even read their bugzilla mail).

Coercion isn't an option that is available to us.

> Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
> that is triggered on the GCC testsuite, it has been known for more
> than 2 months, Janis kindly did a reghunt a month ago to attribute it,
> the patch author was added in the CC list. Since then, nothing
> happened.

This implies that you think it is the patch author's job to fix the
problem.  And if the patch were incorrect, you'd have an argument.
But in this case, it seems that the patch is correct, but it exposes
a problem elsewhere in the compiler (one of Kenner's famous "latent bugs").
Here is the patch:

--- trunk/gcc/cfgexpand.c   2006/12/05 08:49:56 119534
+++ trunk/gcc/cfgexpand.c   2006/12/05 10:15:28 119535
@@ -787,7 +787,8 @@
 add_stack_var (var);
   else
 {
-  expand_one_stack_var (var);
+  if (really_expand)
+expand_one_stack_var (var);
   return tree_low_cst (DECL_SIZE_UNIT (var), 1);
 }
   return 0;

Andrew's comment suggests that the real bug is elsewhere, and I don't get
why the author of the above patch is responsible for fixing that other
breakage.  Reverting the patch is an option, but that would re-open
whatever problems the patch fixed.

Re: Volunteer for bug summaries?

[François-Xavier Coudert]

We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a few more mails (and some people
don't even read their bugzilla mail).


Coercion isn't an option that is available to us.


Hum, I checked the Merriam-Webster dictionary, and clearly "coercive"
was stronger than I thought it was :(  I only mean to say: things can
get fixed by *gentling* pressuring people responsible for it, while
also accepting the pressure when it is applied to yourself.


This implies that you think it is the patch author's job to fix the
problem.


I think it was the patch author's job to either (a) fix the problem or
(b) identify it clearly, and hand it over to the responsible
maintainer.


And if the patch were incorrect, you'd have an argument.
But in this case, it seems that the patch is correct, but it exposes
a problem elsewhere in the compiler (one of Kenner's famous "latent bugs").
[...]
Andrew's comment suggests that the real bug is elsewhere, and I don't get
why the author of the above patch is responsible for fixing that other
breakage.


My first problem with your reasoning is with "suggests": someone has
to do the analysis so that the bug can be correctly assigned and
fixed. If noone is deemed responsible for doing this, then that
regression might stay for years. It sounds not unreasonable to me to
ask the person who committed the patch to do this analysis. After all,
if he had seen it during his regtesting (in that particular case,
testing with Fortran would have probably shown the regression), I
don't think the patch would have been approved, would it?


Reverting the patch is an option, but that would re-open
whatever problems the patch fixed.


And the second issue I see is: unless the patch was actually fixing a
more important regression, which is not the most common case (and not
the case here), you have actually traded a bug (or sometimes, even
only a missed-optimization) for a regression.

FX

Re: Volunteer for bug summaries?

[Janis Johnson]

On Tue, May 22, 2007 at 10:11:27AM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2007-05-22 08:50:59 +0100, Manuel López-Ibáñez <[EMAIL PROTECTED]> 
> wrote:
> > On 22/05/07, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell <[EMAIL PROTECTED]> 
> > > wrote:
> > > > Is there a volunteer who would like to help prepare a regular list of
> > > > P3-and-higher PRs, together with -- where known -- the name of the
> > > > person responsible for the checkin which caused the regression?  Or, is
> > > > this something that could be automated through Bugzilla, perhaps by
> > > > adding a pointer to the SVN revision at which the regression was 
> > > introduced?
> > >
> > > For a start, isn't there enough computation power on the testing
> > > cluster to build all and any revisions of binutils+gcc to run the test
> > > suite?  Shouldn't be hard to implement and would be helpful.  I'd
> > > volunteer to prepare the setup, if somebody supplies the CPU cycles.
> > 
> > I am not sure what you mean exactly. Running the testsuite is not the
> > issue (it must be run for every patch). The discussion is about having
> > a PR with a testcase, then identifying at which revision that testcase
> > started to fail, then identifying who committed that revision.
> 
> Whee...  You're right, I got that wrong. Doesn't change anything about
> scripting work, though. :)
> 
> > Janis has some scripts to do regression hunting. However, it is not
> > fully automatic. For one reason or another, some revisions fail to
> > built. When that happens, you need to mark that revision as ignored
> > and restart the regression hunt. Perhaps you can modify the scripts to
> > handle such situation. Maybe it should also contain a list of "bad"
> > revisions. Apart from this, the scripts are very powerful and
> > intuitive (although some docs would also help everybody).
> > 
> > On the other hand, setting up the regression hunt is not automatic
> > either but with some practice, documentation and fine-tuning of the
> > scripts, it can be made fairly trivial.
> 
> Alas, it sounds like an interesting project and I'd help trying to
> automate it as far as possible.

Many regressions only show up for particularly targets, and wrong-code
regressions usually require executing the failing test for the target
on which it fails.  Full automation wouldn't be easy, and probably
isn't possible.

On the other hand, many PRs already identify the patch that caused
the regression, either because there was a full regression hunt or
because someone examined the ChangeLog entries for a short range in
which the regression occurred and verified that a particular patch
caused the new failure.  Making it easy to search for bugs for which
that information is or is not available, and searching for yourself
as the person who introduced regressions, is a great idea.

Janis

Re: 4.3 release plan

[René Rebe]

On Monday 21 May 2007 20:23:46 Bernardo Innocenti wrote:
> Brooks Moses wrote:
> 
> >> What about moving 4.3 to stage 3 *now* and moving everything
> >> else in 4.4 instead?  Hopefully, it will be a matter of just
> >> a few months.  From http://gcc.gnu.org/gcc-4.3/changes.html,
> >> it looks like it would already be quite a juicy release.
> > 
> > Why?
> >
> > I mean, I suppose there could be advantages to doing this, but you 
> > haven't mentioned even one.
> 
> I apologize.  I guess you could get 10 different reasons
> by 10 different people.

12++

> The reason _we_ care to get 4.3 sooner rather than later
> is that we'd like to have the AMD Geode tuning and the
> memcpy/strcpy() optimizations.
> 
> And also: why not?

Stabelizing a major release series and then continuing to maintain
it is a time consuming efford. With a major series just started
introducing the next just some months later sound like wasting a
lot of our all time.

Backporting the Geode and *cpy tuning for just you local use-case
in contrast is not that hard at all.

Yours,

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

Re: Volunteer for bug summaries?

[Ian Lance Taylor]

"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:

> When the commit which introduced the regression is known, why not
> simply assign the bug to the committer? Surely, people do follow
> regularly the bugs that are assigned to them, don't they?

In practice, no, they don't.

> In my opinion, all regressions should always be assigned to someone,
> at all times. Either to the identified guilty party, or to a volunteer
> or maintainer of that field, who is then responsible for identifying
> the guilty party, or finding someone who accepts to do it. This sounds
> like a reasonable way of making sure some regressions don't get
> forgotten, doesn't it?

It's a reasonable idea, but overall it would have a negative effect.
People tend to ignore PRs that are assigned to somebody else; they
assume that person is actually working on them.  Conversely, people
won't work on a bug simply because it is assigned to them.

I think that what Mark suggested originally is going to be the most,
perhaps the only, effective approach: a volunteer to actually bug
people to get things done, one way or another.  It's not an easy job.
It essentially means acting as a project manager for the compiler
bugs.  The project manager job is hard even when you work in the same
office as the developers, and thus have some ability to actually force
them to do something.  It's much harder when dealing with people
you've never met, only over e-mail.

Ian

Re: Volunteer for bug summaries?

[Manuel López-Ibáñez]

On 22/05/07, Joe Buck <[EMAIL PROTECTED]> wrote:

On Tue, May 22, 2007 at 06:13:58PM +0200, François-Xavier Coudert wrote:
> >CCing the person who caused the regression is more appropriate.  Assigning
> >bugs to them detracts others from fixing the bug.
>
> We already do that, and in lots of cases it doesn't work. CCing is not
> coercive enough, you only receive a few more mails (and some people
> don't even read their bugzilla mail).

Coercion isn't an option that is available to us.



That is why they may unassign themselves from the bug without fear of
reprisal ;-). Generally the list of bugs assigned to one person is
much smaller than the her list of copied bugs. Better than "coercive",
I would say, informative. The point is that you may add to the CC list
a bunch of people that may be interested in the bug but there is a
person that is expected to take some action, even if that action is
washing her hands (=unassigning themselves).



> Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
> that is triggered on the GCC testsuite, it has been known for more
> than 2 months, Janis kindly did a reghunt a month ago to attribute it,
> the patch author was added in the CC list. Since then, nothing
> happened.

This implies that you think it is the patch author's job to fix the
problem.  And if the patch were incorrect, you'd have an argument.
But in this case, it seems that the patch is correct, but it exposes
a problem elsewhere in the compiler (one of Kenner's famous "latent bugs").


So it would be fair for the author to say so and unassign himself. Or
perhaps the author has some idea of what is going on and could assign
to someone else. This is not "blaming", it is just a way to deal with
the issue of people believing that it is someone else's turn to take
action.


Andrew's comment suggests that the real bug is elsewhere, and I don't get
why the author of the above patch is responsible for fixing that other
breakage.  Reverting the patch is an option, but that would re-open
whatever problems the patch fixed.


You got to this conclusion because you took the time to analyse the
patch and to realise that it wasn't the cause of the problem. The
point is that we may hope the patch author to do that work (unless
someone does it before) and then take whatever action seems
appropriate (assign to other person or just to nobody). I think that
is a fair hope and may solve the issue that Mark raised.

Cheers,

Manuel.

Re: Volunteer for bug summaries?

[David Edelsohn]

> Joe Buck writes:

Joe> This implies that you think it is the patch author's job to fix the
Joe> problem.  And if the patch were incorrect, you'd have an argument.
Joe> But in this case, it seems that the patch is correct, but it exposes
Joe> a problem elsewhere in the compiler (one of Kenner's famous "latent bugs").

Joe> Andrew's comment suggests that the real bug is elsewhere, and I don't get
Joe> why the author of the above patch is responsible for fixing that other
Joe> breakage.  Reverting the patch is an option, but that would re-open
Joe> whatever problems the patch fixed.


The GCC development plan tries to place the responsibility on the
original author, whether or not the bug was in the patch or the patch
exposed a latent bug.  If the responsibility is not placed on the patch
author, then effectively no one is responsible, other than the release
manager.  This is too large and impractical a burden for the RM, which
effectively means that fixing the bug is left to someone else's motivation
or good graces.  The original author may not be able to fix the bug
himself or herself, but should be responsible for finding someone to fix
it.

If anyone has better ideas for distributing the responsibility and
for generating enough responsibility so that the bug or regression does
not languish, please speak up.  Hopefully with weekly or bi-monthly
reports, all GCC developers will be more aware of open problems and
developers who caused bugs or exposed latent problems will be encouraged
to fix them, get help fixing them, or find someone to fix them.

David

DF branch benchmarking on SPEC2000

[Vladimir N. Makarov]

 Ken Zadeck asked me to do another round of DF branch benchmarking on
SPEC2000.  There is a progress on compilation speed (0.5%-1%) since
last my benchmarking pratically for all platforms.  Now in average
code size and SPEC scores are practically the same for the mainline
and the branch.  To be honest I am not worried anymore about the
branch because most serious degradations were fixed a few weeks ago.
Because people working on the branch are determined to add the code
for 4.3 release, so may be it is worth to plan the merge of
the branch into the mainline to have more time to fix bugs on minor
platforms (of course if people find them).

 So this is latest df-branch (with latest Ken Zadeck's
patches)/mainline(r124833) comparison after the last merge to the branch
(done 05/18).  When the merge was done, fma3d was broken on the
mainline.  Therefore the results for SPECFP are given without this
benchmark.  My scripts also failed to produce code size change for
x86_64.

 All toolchains were compiled with --enable-checking=release (-O2 was
used to SPEC2000 benchmarks).  Four platforms for benchmarking were
used:

x86_64: 2.6 Ghz Core2.
Itanium: 1.6Ghz Itanium2.
PPC64: 2.5Ghz G5.
Pentium4: 3.2Ghz Pentium4 (additionally -mtune=pentium4 was used).

The attachments contain more verbose info about SPEC2000 results
(there base is df-branch, peak is mainline on the merge point).

Here is the summary:

Compilation time SPECINT2000 (user time sec):
**Mainline Branch Change

x86_64139.96   148.15   +5.8%
Itanium   441.01   476.72   +8.1%
PPC64 375.41   399.43   +6.3%
Pentium4  252.67   269.27   +6.5%

Compilation time SPECFP2000 (user time sec):
**Mainline Branch Change

x86_64 94.64   102.02   +7.7%
Itanium   331.56   370.22  +11.6%   
PPC64 296.11   298.75   +0.9%

Pentium4  168.99   180.48   +6.7%

Code Size SPECINT2000 (text segment)
**Change

x86_64-
Itanium   -0.10%
PPC64 -0.10%
Pentium4  +0.11%

Code Size SPECFP2000 (text segment)
**Change

x86_64-
Itanium   -0.21%
PPC64 -0.06%
Pentium4  +0.02%

SPECINT200 Scores:
**Mainline Branch Change

x86_641939 1937   -0.10%
Itanium866  865   -0.12%
PPC64  674  674   0%
Pentium4   897  897   0%

SPECFP200 Scores:
**Mainline Branch Change

x86_641782 1775   -0.39%
Itanium552  548   -0.72%
PPC64  618  619   +0.16%
Pentium4   686  682   -0.58%

 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
               
   164.gzip  1400  99.1  1412  1400  99.8  1402 
   164.gzip  1400  99.2  1411  1400  99.9  1401 
   164.gzip  1400  99.1  1412* 1400  99.9  1402*
   175.vpr   1400  86.5  1619  1400  86.7  1614*
   175.vpr   1400  86.5  1619* 1400  86.8  1612 
   175.vpr   1400  86.4  1620  1400  86.6  1617 
   176.gcc   1100  60.0  1833  1100  60.3  1826*
   176.gcc   1100  60.0  1833* 1100  60.2  1827 
   176.gcc   1100  60.0  1832  1100  60.3  1825 
   181.mcf   1800 1141581  1800 1131587*
   181.mcf   1800 1131588  1800 1141583 
   181.mcf   1800 1141585* 1800 1131592 
   186.crafty1000  38.8  2579  1000  38.6  2587 
   186.crafty1000  38.8  2578  1000  38.6  2587*
   186.crafty1000  38.8  2578* 1000  38.6  2588 
   197.parser1800 1441253  1800 1441253*
   197.parser1800 1441254  1800 1441253 
   197.parser1800 1441253* 1800 1441253 
   252.eon   1300  55.8  2329  1300  52.6  2471*
   252.eon   1300  55.9  2326  1300  52.7  2467 
   252.eon   1300  55.8  2329* 1300  52.6  2471 
   253.perlbmk   1800  70.5  2554  1800  72.3  2489 
   253.perlbmk   1800  70.4  2557* 1800  72.3  2491*
   253.perlbmk   1800  70.4  2558  1800  72.2  2492 
   254.gap   1100  54.4  2020  1100  54.6  2013*
   254.gap   1100  54.3  2024  1100  54.6  2015 
   254.gap   1100  54.4  2021* 1

Re: Volunteer for bug summaries?

[Daniel Berlin]

On 5/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more importantly, what regressions they may have caused.

Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs, together with -- where known -- the name of the
person responsible for the checkin which caused the regression?  Or, is
this something that could be automated through Bugzilla, perhaps by
adding a pointer to the SVN revision at which the regression was introduced?


Oh, uh, one thing that might help here is that bugzilla 3.0 supports
sharing of saved searches.

That would enable us to simply share the search that produces the list
of "currently open P3 and higher PR", and it would just appear for
everyone at the bottom of the page under saved searches.

(Or i can put it on the bugzilla front page in the initial link list,
titled "Find a bug to work on!")



The goal would be to send a weekly/bi-weekly reminder to the list, and
to the responsible parties, to help remind those of us who've caused
problems to clean them up.  I know that this would help me, both as a
developer and as the RM: as RM, it would help me see what's going on,
and as a developer, it would encourage me to clean up my messes, even
when I'm busy.

What do others think?


The patch queue is also capable of producing a list of open PR's that
have outstanding unreviewed patches that are there, and emailing it
out.

As  somewhat related aside to this topic, I've been looking into
integrating the patch queue  with something like reviewboard
(http://code.google.com/p/reviewboard/  screenshots/etc at
http://www.chipx86.com/blog/?p=222)
after adding some serious incoming email handling to reviewboard, to
see if most reviews and outstanding patches for existing PR's can't be
tracked completely.

I know about 75% of our maintainers prefer email only for reviewing
patches, and about 25% would prefer a web based solution :).

I'm trying to see if i can't accomodate both while simultaneously
making sure none of our PR's fall through the cracks easily.

Re: Volunteer for bug summaries?

[Andrew Pinski]

On 5/22/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:

Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
that is triggered on the GCC testsuite, it has been known for more
than 2 months, Janis kindly did a reghunt a month ago to attribute it,
the patch author was added in the CC list. Since then, nothing
happened.


I have a fix for this bug, as mentioned by me, it is unrelated to the
patch which caused it, I have no idea how the patch which exposed the
bug even exposed it really.  I guess I need to take this weekend to
fix regressions again :).

The fix by the way is an one liner too.

Thanks,
Andrew Pinski

Re: Volunteer for bug summaries?

[Daniel Berlin]

On 5/22/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:

> CCing the person who caused the regression is more appropriate.  Assigning
> bugs to them detracts others from fixing the bug.

We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a few more mails (and some people
don't even read their bugzilla mail).

Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
that is triggered on the GCC testsuite, it has been known for more
than 2 months, Janis kindly did a reghunt a month ago to attribute it,
the patch author was added in the CC list. Since then, nothing
happened.

I'm taking this example because I was remembered about it by a mail on
the fortran list, but it has nothing specific, there are scores of
these kind out there. I think assigning regressions to people who
introduced them is only fair, after all, they are supposed to take
care of it or find someone else to do it!


On the other side of the fence, I get CC'd on lot of "bugs" in PRE
that turn out to be problems elsewhere, and just happen to be exposed
because PRE has a lot of asserts in it.  Our other optimization passes
are more lenient.   :)

Two of these in the past week, in fact.

I generally assign myself bugs when i'm actually working on a patch,
instead of just looking at it.

Re: Regressions -march=geode/athlon regressions (Was: 4.3 release plan)

[Bernardo Innocenti]

Bernardo Innocenti wrote:

> I'm currently bootstrapping 4.2 with "--with-arch=geode"
> and will run the testsuite shortly.

It took a little longer than I expected because I was
seeing a few new regressions:

FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O0
FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O1
FAIL: gcc.c-torture/execute/20050316-2.c execution,  -O2
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O0
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O1
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O2
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer 
-funroll-loops
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -Os
FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: gcc.dg/builtin-apply4.c execution test

But then it turned out that using --with-arch=athlon produces
exactly the same regressions, while --with-arch=i586 is fine.

I analyzed only the first failing test.  It seems we fail
with all MMX enabled processors. But maybe the test has
invalid expectations, I'm not sure what it is trying to do.

 WORKS: gcc -O0 -march=i686   gcc.c-torture/execute/20050316-2.c && ./a.out
 FAILS: gcc -O0 -march=athlon gcc.c-torture/execute/20050316-2.c && ./a,out

This is with 4.2-branch, but it also happens with FC6's gcc-4.1.1.

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/

Re: Volunteer for bug summaries?

[Mark Mitchell]

Ian Lance Taylor wrote:

[Danny, please see below for a request for your help.]

> It's a reasonable idea, but overall it would have a negative effect.
> People tend to ignore PRs that are assigned to somebody else; they
> assume that person is actually working on them.  Conversely, people
> won't work on a bug simply because it is assigned to them.

Right.

I'm going to back up and try to explain a bit more about what I'm trying
to accomplish.

One of the problems I've faced in recent releases is that developers
seem not to care too much about fixing bugs, even bugs that they've
caused.  On the other hand, I know from talking to users that they care
a lot about bugs.  There's a large class of users whose basic goal from
a new version of GCC is to get better run-time performance from their
code, without having to change their code.  Bugs, and regressions in
particular, are a serious problem for these users.

I think GCC developers are well-intentioned, but busy.  Many of us are
working on GCC at least partially as volunteers, and relatively few of
us are particularly incentivized to worry about problems we may have
caused on systems we don't use, or codebases we don't compile.  But, I
think that many of us would respond to being nagged about relatively
high-priority regressions, and that if we begin to address these
problems earlier in the release cycle, that will help the project overall.

I also think that a fundamental responsibility for those of us with
check-in privileges is to clean up after ourselves.  That's why we've
said -- correctly, in my opinion -- that the "latent bug" excuse is no
excuse at all; it's each contributor's responsibility to try to ensure
that their contributions make the compiler monotonically better.  One
would hope that once a contributor tracks down a bug as being a latent
bug that an appropriate maintainer would help fix the latent bug, but
there's only one person who has the obvious responsibility to
investigate/fix the problem: the person who contributed the change that
caused/exposed it.

One of the reasons that we have bug priorities is so that we can ignore
unimportant bugs.  That's also why I've established a procedure to allow
people beside me to flag PRs for downgrading.  If you contribute a great
new optimization, and it causes us to generate an inferior error message
for some obscure test case, then that's a regression -- but we should
mark it P4, and you shouldn't have to worry about it.  On the other
hand, if your great new optimization causes wrong code on a major
platform, then you should figure out why, and arrange to fix the problem.

In any case, theory aside, here is what I would like to do:

1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced.  Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin.  This field value ought to be the most
recent revision to the GCC trunk such that the bug did not occur in the
previous revision, but does occur in all subsequent revisions.

Danny B., would you be willing to do this?

2. Ask volunteers to fill in the field.

Independent of what you may think of my philosophical statements above,
this is useful data.  One of the first things many of us do when trying
to debug a new problem is figure out what changed to cause it.  And,
this is work that even a volunteer without great knowledge of the
compiler's internals can help with, perhaps using Janis' scripts to help
with testing.

3. Set up a cron job to generate mail to people whose name is in the
ChangeLog entries for P3 and higher regressions, with the SVN field
filled in.

I will volunteer to work on this part of things, but hopefully I can get
some help from our SVN and Bugzilla experts.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713