On 10/29/2010 12:35 AM, Andrew Pinski wrote:
The important part of the log is:
/bin/sh ./libtool --tag=CC --mode=compile
/Users/regress/tbox/native/build/./gcc/xgcc
-B/Users/regress/tbox/native/build/./gcc/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/
-B/Users/regress/tbox/objs/pow
-recursive] Error 1
make[1]: *** [all-target-boehm-gc] Error 2
make[1]: *** Waiting for unfinished jobs
-- Forwarded message --
From: regress
Date: Thu, Oct 28, 2010 at 12:49 PM
Subject: NEW GCC build failure, h...@166030 on native
To: gcc-regress...@gcc.gnu.org
With your recent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 03/07/2009 15:58, Laurent GUERBY a écrit :
[...]
> Right now the bootstrap+check loops I run on the compile farm cover the
> following *-linux platforms with c,ada unless otherwise specified:
>
> gcc13 x86_64trunk 3h30
> gcc15 x86_644.4
On Fri, 2009-07-03 at 07:43 +0200, Paolo Bonzini wrote:
> On 07/03/2009 07:31 AM, Eric Botcazou wrote:
> >> This was pretty bad, but it was also unlucky that the failure was only
> >> on the exact arch that the tester builds for. Failures on powerpc are
> >> extremely annoying, failures on SPARC w
What is wrong about failures being annoying?
Paolo, you could have reverted your original patch and worked with the
PowerPC developers to test a revised patch.
If I had been asked, I would have.
Paolo
On Thu, Jul 2, 2009 at 5:23 PM, Paolo Bonzini wrote:
> Well, if the failure is in libgcc, that means that we get a mail on every
> commit. In this case my patch went in on Sunday afternoon, and the problems
> were fixed only on Thursday for multiple reasons (multiple patches, need for
> approval,
On 07/03/2009 07:31 AM, Eric Botcazou wrote:
This was pretty bad, but it was also unlucky that the failure was only
on the exact arch that the tester builds for. Failures on powerpc are
extremely annoying, failures on SPARC will go (almost) unnoticed.
Not clear what you mean about SPARC. The
> This was pretty bad, but it was also unlucky that the failure was only
> on the exact arch that the tester builds for. Failures on powerpc are
> extremely annoying, failures on SPARC will go (almost) unnoticed.
Not clear what you mean about SPARC. The recent multiple SPARC breakages had
been
> The powerpc tester won't do a run more often than once every 15
> minutes
Well, if the failure is in libgcc, that means that we get a mail on
every commit. In this case my patch went in on Sunday afternoon, and
the problems were fixed only on Thursday for multiple reasons (multiple
patches
On Jul 2, 2009, at 2:35 AM, Richard Guenther
wrote:
On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres> wrote:
In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
Arnaud Charlet wrote:
Can someone please fix or disable these runs? They are getting very
irritating.
What I find e
Sent from my iPhone
On Jul 2, 2009, at 4:18 AM, Paolo Bonzini wrote:
On 07/02/2009 12:06 PM, Dominique Dhumieres wrote:
Andrew Haley wrote
Is this really a good idea? Surely the solution is to fix the
failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failur
On 07/02/2009 03:09 PM, Dominique Dhumieres wrote:
Note that revision 149171 not only breaks powerpc-apple-darwin9.7.0
but now also i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00114.html).
I don't see any of the new failures reported in that message.
Paolo
Note that revision 149171 not only breaks powerpc-apple-darwin9.7.0
but now also i686-pc-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00114.html).
Dominique
On 07/02/2009 12:06 PM, Dominique Dhumieres wrote:
Andrew Haley wrote
Is this really a good idea? Surely the solution is to fix the
failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failure
was Darwin specific and is now fixed, two others are powerpc ones.
When t
Andrew Haley wrote
> Is this really a good idea? Surely the solution is to fix the
> failures on Darwin.
I don't this is a good idea. As noted by Andrew Pinski, one failure
was Darwin specific and is now fixed, two others are powerpc ones.
When they will be fixed on trunk the annoying mails will
On Thu, Jul 2, 2009 at 2:41 AM, Andrew Pinski wrote:
> On Thu, Jul 2, 2009 at 2:35 AM, Richard
> Guenther wrote:
>> But yes, Geoff - can you adjust the regression mails to not blame
>> people for build failures that persist for some time?
>
> except it was three different failures; two have been fi
On Thu, Jul 2, 2009 at 2:35 AM, Richard
Guenther wrote:
> But yes, Geoff - can you adjust the regression mails to not blame
> people for build failures that persist for some time?
except it was three different failures; two have been fixed and the
last one has been approved.
--Pinski
Richard Guenther wrote:
> On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres
> wrote:
>> In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
>> Arnaud Charlet wrote:
>>> Can someone please fix or disable these runs? They are getting very
>>> irritating.
>> What I find extremely irritat
On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres wrote:
> In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
> Arnaud Charlet wrote:
>> Can someone please fix or disable these runs? They are getting very
>> irritating.
>
> What I find extremely irritating is that it takes so long to
In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
Arnaud Charlet wrote:
> Can someone please fix or disable these runs? They are getting very
> irritating.
What I find extremely irritating is that it takes so long to
fix bootstrap failures. Meanwhile I hope to see such mails
until the
On Sat, Feb 28, 2009 at 9:31 AM, H.J. Lu wrote:
>> In file included from /usr/include/features.h:354,
>> from /usr/include/stdio.h:28,
>> from ../../../../libgcc/../gcc/tsystem.h:90,
>> from ../../../../libgcc/../gcc/libgcc2.c:34:
>> /usr/include/gnu
On Sat, Feb 28, 2009 at 9:27 AM, Bruce Korb wrote:
> Hi all,
>
> This got far enough along to run fixincludes, so I can test this
> ``Old GCC-on-Tru64 bugfix'' thing, but still. Using current SVN source:
>
> # If this is the top-level multilib, build all the other
> # multilibs.
> /home/gnu/proj/
Hi all,
This got far enough along to run fixincludes, so I can test this
``Old GCC-on-Tru64 bugfix'' thing, but still. Using current SVN source:
# If this is the top-level multilib, build all the other
# multilibs.
/home/gnu/proj/gcc/_bld/./gcc/xgcc -B/home/gnu/proj/gcc/_bld/./gcc/
-B/usr/local
23 matches
Mail list logo
