This is the mail archive of the
mailing list for the GCC project.
Re: GCC Buildbot
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Paulo Matos <email@example.com>, gcc at gcc dot gnu dot org, Sergio Durigan Junior <sergiodj at redhat dot com>, dje dot gcc at gmail dot com
- Date: Thu, 21 Sep 2017 07:18:38 +0200
- Subject: Re: GCC Buildbot
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20170920230135.GU8421@gate.crashing.org>
On 2017.09.20 at 18:01 -0500, Segher Boessenkool wrote:
> On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
> > This mail's intention is to gauge the interest of having a buildbot for
> > GCC.
> +1. Or no, +100.
> > - which machines we can use as workers: we certainly need more worker
> > (previously known as slave) machines to test GCC in different
> > archs/configurations;
> I think this would use too much resources (essentially the full machines)
> for the GCC Compile Farm. If you can dial it down so it only uses a
> small portion of the machines, we can set up slaves there, at least on
> the more unusual architectures. But then it may become too slow to be
There is already a buildbot that uses GCC compile farm resources:
And it has the basic problem of all automatic testing: that in the long
run everyone simply ignores it.
The same thing would happen with the proposed new buildbot. It would use
still more resources on the already overused machines without producing
The same thing is true for the regression mailing list
It is obvious that nobody pays any attention to it, e.g. PGO bootstrap
is broken for several months on x86_64 and i686 bootstrap is broken for
a long time, too.
Only a mandatory pre-commit hook that would reject commits that break
anything would work. But running the testsuite takes much to long to
make this approach feasible.