Re: Re: GCC build failure, HEAD@149166 on native

Re: Re: GCC build failure, HEAD@149166 on native

[Dominique Dhumieres]

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 problem(s) is (are) fixed.

Dominique

Re: Re: GCC build failure, HEAD@149166 on native

[Richard Guenther]

On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres<dominiq@lps.ens.fr> 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
> fix bootstrap failures. Meanwhile I hope to see such mails
> until the problem(s) is (are) fixed.

Well, I suppose "native" is *-darwin which then boils down to the fact
that this is not a freely available host operating system and the
respective maintainers of that target/host combination seem to not
care.

But yes, Geoff - can you adjust the regression mails to not blame
people for build failures that persist for some time?

Thanks,
Richard.

> Dominique
>

Re: GCC build failure, HEAD@149166 on native

[Andrew Haley]

Richard Guenther wrote:
> On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres<dominiq@lps.ens.fr> 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
>> fix bootstrap failures. Meanwhile I hope to see such mails
>> until the problem(s) is (are) fixed.
> 
> Well, I suppose "native" is *-darwin which then boils down to the fact
> that this is not a freely available host operating system and the
> respective maintainers of that target/host combination seem to not
> care.
> 
> But yes, Geoff - can you adjust the regression mails to not blame
> people for build failures that persist for some time?

Is this really a good idea?  Surely the solution is to fix the
failures on Darwin.

Andrew.

Re: Re: GCC build failure, HEAD@149166 on native

[Andrew Pinski]

On Thu, Jul 2, 2009 at 2:35 AM, Richard
Guenther<richard.guenther@gmail.com> 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

Re: Re: GCC build failure, HEAD@149166 on native

[Andrew Pinski]

On Thu, Jul 2, 2009 at 2:41 AM, Andrew Pinski<pinskia@gmail.com> wrote:
> On Thu, Jul 2, 2009 at 2:35 AM, Richard
> Guenther<richard.guenther@gmail.com> 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.

oh and two effected powerpc-linux too including the current one ...

--Pinski

Re: Re: GCC build failure, HEAD@149166 on native

[Dominique Dhumieres]

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 automatically
disappear.

Dominique

Re: GCC build failure, HEAD@149166 on native

[Paolo Bonzini]

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 they will be fixed on trunk the annoying mails will automatically
> disappear.

However, this does not mean that tuning the regression tester to not 
sending more than 6 emails a day (one every 4 hours) would be a bad idea.

Paolo

Re: GCC build failure, HEAD@149166 on native

[Dominique Dhumieres]

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

Re: GCC build failure, HEAD@149166 on native

[Paolo Bonzini]

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

Re: GCC build failure, HEAD@149166 on native

[Andrew Pinski]

Sent from my iPhone

On Jul 2, 2009, at 4:18 AM, Paolo Bonzini <bonzini@gnu.org> 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 failure
>> was Darwin specific and is now fixed, two others are powerpc ones.
>> When they will be fixed on trunk the annoying mails will  
>> automatically
>> disappear.
>
> However, this does not mean that tuning the regression tester to not  
> sending more than 6 emails a day (one every 4 hours) would be a bad  
> idea.

It is once every commit until it is fixed which seems like the correct  
way of doing it really. We really should be frozen during the period  
it is broken. Otherwise more things break like what happened here.

--Pinski

>
> Paolo

Re: GCC build failure, HEAD@149166 on native

[Geoff Keating]

On Jul 2, 2009, at 2:35 AM, Richard Guenther  
<richard.guenther@gmail.com> wrote:

> On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres<dominiq@lps.ens.fr 
> > 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
>> fix bootstrap failures. Meanwhile I hope to see such mails
>> until the problem(s) is (are) fixed.
>
> Well, I suppose "native" is *-darwin which then boils down to the fact
> that this is not a freely available host operating system and the
> respective maintainers of that target/host combination seem to not
> care.
>
> But yes, Geoff - can you adjust the regression mails to not blame
> people for build failures that persist for some time?

The regression tester's mail should not be taken as blaming anyone for  
anything. It's a machine and not yet capable of such complex thoughts.

Indeed, it's not capable of reliably working out whether a build  
failure has persisted for some time or has changed. At present it  
looks at the log file length but because the log file length can vary  
for many reasons it can have both false positives and false negatives.

The powerpc tester won't do a run more often than once every 15  
minutes, and that only if the build fails that quickly (indicating a  
pretty bad build breakage) and there are commits since the previous  
run. In those circumstances I think it's reasonable to hope that the  
commit will fix the build breakage and so should be tested as quickly  
as possible...

If anyone is having trouble reproducing a problem reported by the  
tester, send me mail!
>

Re: GCC build failure, HEAD@149166 on native

[Paolo Bonzini]

 > 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, need for approval, need to rely on Peter Bergner to test 
patches, possibility to work with him only when both of us were awake, 
etc.).

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.

Paolo

Re: GCC build failure, HEAD@149166 on native

[Eric Botcazou]

> 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 reported for weeks in PRs and the problematic patch clearly identified.

-- 
Eric Botcazou

Re: GCC build failure, HEAD@149166 on native

[Paolo Bonzini]

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 recent multiple SPARC breakages had
> been reported for weeks in PRs and the problematic patch clearly identified.

Yeah, but it's nothing compared to the nagging for powerpc-darwin. 
Maintainers and other frequent testers of SPARC notice it, and that's 
it.  While everyone is going to notice the failures from Geoff's 
regression tester, like Arnaud did.

Paolo

Re: GCC build failure, HEAD@149166 on native

[David Edelsohn]

On Thu, Jul 2, 2009 at 5:23 PM, Paolo Bonzini<bonzini@gnu.org> 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, need to rely on Peter Bergner to test patches, possibility to work
> with him only when both of us were awake, etc.).
>
> 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.

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.

David

Re: GCC build failure, HEAD@149166 on native

[Paolo Bonzini]

> 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

Re: GCC build failure, HEAD@149166 on native

[Laurent GUERBY]

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 will go (almost) unnoticed.
> >
> > Not clear what you mean about SPARC.  The recent multiple SPARC breakages had
> > been reported for weeks in PRs and the problematic patch clearly identified.
> 
> Yeah, but it's nothing compared to the nagging for powerpc-darwin. 
> Maintainers and other frequent testers of SPARC notice it, and that's 
> it.  While everyone is going to notice the failures from Geoff's 
> regression tester, like Arnaud did.

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_64    trunk   3h30
gcc15 x86_64    4.4     6h30 (-j 2)
gcc40 powerpc64 trunk   6h00
gcc50 armv5tel  trunk 112h00 (c,c++,fortran)
gcc51 mips64el  trunk  21h00 tri ABI
gcc53 powerpc   trunk   8h00
gcc54 sparc     trunk  25h00
gcc60 ia64      trunk   8h30
gcc61 hppa      trunk  22h00
gcc62 sparc64   trunk  28h00

Currently my script loops silently in case of bootstrap failure. I can
make the script send a mail to gcc-regression@ when bootstrap state
change (work then fail, and fail then work) if there's consensus it's
useful (I don't know if people follow gcc-regression@).

Sincerely,

Laurent

Re: GCC build failure, HEAD@149166 on native

[Dodji Seketeli]

-----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_64    trunk   3h30
> gcc15 x86_64    4.4     6h30 (-j 2)
> gcc40 powerpc64 trunk   6h00
> gcc50 armv5tel  trunk 112h00 (c,c++,fortran)
> gcc51 mips64el  trunk  21h00 tri ABI
> gcc53 powerpc   trunk   8h00
> gcc54 sparc     trunk  25h00
> gcc60 ia64      trunk   8h30
> gcc61 hppa      trunk  22h00
> gcc62 sparc64   trunk  28h00
> 
> Currently my script loops silently in case of bootstrap failure. I can
> make the script send a mail to gcc-regression@ when bootstrap state
> change (work then fail, and fail then work) if there's consensus it's
> useful (I don't know if people follow gcc-regression@).

It would certainly be useful to me at least as I check gcc-regression
before fetching new bits from the gcc repository.

Thanks.

- -- 
Dodji Seketeli
Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkpOI9cACgkQPejI7lrem2GVxQCgvQKX5RsDVfIcLhurKJSrk9Eh
dkMAnj2iRT1APLvnopyYaQMdF858wIhG
=M6Wz
-----END PGP SIGNATURE-----