On 2017.09.20 at 18:01 -0500, Segher Boessenkool wrote: > Hi! > > 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 > useful.
There is already a buildbot that uses GCC compile farm resources: http://toolchain.lug-owl.de/buildbot/ 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 useful results. The same thing is true for the regression mailing list https://gcc.gnu.org/ml/gcc-regression/current/. 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. -- Markus
