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.
