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 s
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 f
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 lis
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 an
-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
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
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 identi
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 a
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: logica
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 m
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,
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 "coerciv
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]>
> > > w
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
"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, a
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
> 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'
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 ho
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 he
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
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
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/2005
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
23 matches
Mail list logo
