Re: GCC Buildbot Update
On 14/12/17 12:39, David Malcolm wrote: > > Looking at some of the red blobs in e.g. the grid view there seem to be > a few failures in the initial "update gcc trunk repo" step of the form: > > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Yes, that's a big annoyance and a reason I have thought about moving to using the git mirror, however that would probably bring other issues so I am holding off. I need to add a reporter so that if it fails I am notified by email and mobile phone. This happens when there's a timeout from a server _during_ a checkout/update (the svn repo unfortunately times out way too often). I thought about doing an svn cleanup before each checkout but read it's not good practice. If you have any suggestions on this please let me know. > https://gcc-lnt.linki.tools/#/builders/3/builds/388/steps/0/logs/stdio > Apologies, https://gcc-lnt.linki.tools is currently incorrectly forwarding you to https://gcc-buildbot.linki.tools. I meant to have it return an error until I open that up. > Is there a bug-tracking location for the buildbot? > Presumably: > https://github.com/LinkiTools/gcc-buildbot/issues > ? > That's correct. > I actually found a serious bug in jamais-vu yesterday - it got confused > by multiple .sum lines for the same source line e.g. from multiple > "dg-" directives that all specify a particular line). For example, > when testing one of my patches, of the 3 tests reporting as > "c-c++-common/pr83059.c -std=c++11 (test for warnings, line 7)" > one of the 3 PASS results became a FAIL. jv correctly reported that > new FAILs had occurred, but wouldn't identify them, and mistakenly > reported that new PASSes has occurred also. > > I've fixed that now; to do so I've done some refactoring and added a > testsuite. > Perfect, thank you very much for this work. > It looks like you're capturing the textual output from "jv compare" and > using the exit code. Would you prefer to import "jv" as a python > module and use some kind of API? Or a different output format? > Well, I am using a fork of it which I converted to Python3. Would you be open to convert yours to Python3? The reason I am doing this is because all other Python software I have and the buildbot use Python3. I would also prefer to have some json format or something but when I looked at it, the software was just printing to stdout and I didn't want to spend too much time implementing it, so I thought parsing the output was just easier. > If you file pull request(s) for the changes you've made in your copy of > jamais-vu, I can take at look at merging them. > Happy to do so... Will merge your changes into my fork first then. Kind regards, -- Paulo Matos
Re: GCC Buildbot Update
On 14/12/17 21:32, Christophe Lyon wrote: > Great, I thought the CF machines were reserved for developpers. > Good news you could add builders on them. > Oh. I have seen similar things happening on CF machines so I thought it was not a problem. I have never specifically asked for permission. >> pmatos@gcc115:~/gcc-8-20171203_BUILD$ as -march=armv8.1-a >> Assembler messages: >> Error: unknown architecture `armv8.1-a' >> >> Error: unrecognized option -march=armv8.1-a >> >> However, if I run the a compiler build manually with just: >> >> $ configure --disable-multilib >> $ nice -n 19 make -j4 all >> >> This compiles just fine. So I am at the moment attempting to investigate >> what might cause the difference between what buildbot does and what I do >> through ssh. >> > I suspect you are hitting a bug introduced recently, and fixed by: > https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html > Wow, that's really useful. Thanks for letting me know. -- Paulo Matos
Re: GCC Buildbot Update
On 15 December 2017 at 10:19, Paulo Matos wrote: > > > On 14/12/17 21:32, Christophe Lyon wrote: >> Great, I thought the CF machines were reserved for developpers. >> Good news you could add builders on them. >> > > Oh. I have seen similar things happening on CF machines so I thought it > was not a problem. I have never specifically asked for permission. > >>> pmatos@gcc115:~/gcc-8-20171203_BUILD$ as -march=armv8.1-a >>> Assembler messages: >>> Error: unknown architecture `armv8.1-a' >>> >>> Error: unrecognized option -march=armv8.1-a >>> >>> However, if I run the a compiler build manually with just: >>> >>> $ configure --disable-multilib >>> $ nice -n 19 make -j4 all >>> >>> This compiles just fine. So I am at the moment attempting to investigate >>> what might cause the difference between what buildbot does and what I do >>> through ssh. >>> >> I suspect you are hitting a bug introduced recently, and fixed by: >> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html >> > > Wow, that's really useful. Thanks for letting me know. > And the patch was committed last night (r255659), so maybe your builds now work? > -- > Paulo Matos
Re: GCC Buildbot Update
On 15/12/17 08:42, Markus Trippelsdorf wrote: > > I don't think this is good news at all. > As I pointed out in a reply to Chris, I haven't seeked permission but I am pretty sure something similar runs in the CF machines from other projects. The downside is that if we can't use the CF, I have no extra machines to run the buildbot on. > Once a buildbot runs on a CF machine it immediately becomes impossible > to do any meaningful measurement on that machine. That is mainly because > of the random I/O (untar, rm -fr, etc.) of the bot. As a result variance > goes to the roof and all measurements drown in noise. > > So it would be good if there was a strict separation of machines used > for bots and machines used by humans. In other words bots should only > run on dedicated machines. > I understand your concern though. Do you know who this issue could be raised with? FSF? -- Paulo Matos
Re: GCC Buildbot Update
On 15/12/17 10:21, Christophe Lyon wrote: > And the patch was committed last night (r255659), so maybe your builds now > work? > Forgot to mention that. Yes, it built! https://gcc-buildbot.linki.tools/#/builders/5 -- Paulo Matos
Re: GCC Buildbot Update
On 2017.12.15 at 10:21 +0100, Paulo Matos wrote: > > > On 15/12/17 08:42, Markus Trippelsdorf wrote: > > > > I don't think this is good news at all. > > > > As I pointed out in a reply to Chris, I haven't seeked permission but I > am pretty sure something similar runs in the CF machines from other > projects. > > The downside is that if we can't use the CF, I have no extra machines to > run the buildbot on. > > > Once a buildbot runs on a CF machine it immediately becomes impossible > > to do any meaningful measurement on that machine. That is mainly because > > of the random I/O (untar, rm -fr, etc.) of the bot. As a result variance > > goes to the roof and all measurements drown in noise. > > > > So it would be good if there was a strict separation of machines used > > for bots and machines used by humans. In other words bots should only > > run on dedicated machines. > > > > I understand your concern though. Do you know who this issue could be > raised with? FSF? I think the best place would be the CF user mailing list . (All admins and users should be subscribed.) -- Markus
Re: GCC Buildbot Update
On Fri, 2017-12-15 at 10:16 +0100, Paulo Matos wrote: > > On 14/12/17 12:39, David Malcolm wrote: [...] > > It looks like you're capturing the textual output from "jv compare" > > and > > using the exit code. Would you prefer to import "jv" as a python > > module and use some kind of API? Or a different output format? > > > > Well, I am using a fork of it which I converted to Python3. Would you > be > open to convert yours to Python3? The reason I am doing this is > because > all other Python software I have and the buildbot use Python3. Done. I found and fixed some more bugs, also (introduced during my refactoring, sigh...) > I would also prefer to have some json format or something but when I > looked at it, the software was just printing to stdout and I didn't > want > to spend too much time implementing it, so I thought parsing the > output > was just easier. I can add JSON output (or whatever), but I need to get back to gcc 8 work, so if the stdout output is good enough for now, let's defer output changes. > > If you file pull request(s) for the changes you've made in your > > copy of > > jamais-vu, I can take at look at merging them. > > > > Happy to do so... > Will merge your changes into my fork first then. > > Kind regards,
Re: Register Allocation Graph Coloring algorithm and Others
On 12/14/17 9:18 PM, Leslie Zhai wrote: > * The papers by Briggs and Chaiten contradict[2] themselves when examine > the text of the paper vs. the pseudocode provided? I've read both of these papers many times (in the past) and I don't recall any contradictions in them. Can you (Dave?) be more specific about what you think are contradictions? I do admit that pseudo code in papers can be very terse, to the point that they don't show all the little details that are needed to actually implement them, but they definitely shouldn't contradict their written description. I was very grateful that Preston was more than willing to answer all my many questions regarding his allocator and the many many details he couldn't mention in his Ph.D. thesis, let alone a short paper. Peter
Re: Conversion progress report
On Thu, Dec 14, 2017 at 10:16:15PM +, Joseph Myers wrote: > There's a policy question we'll need to figure out for after the > conversion of whether we want to have a branch namespace where people can > push branches that can be deleted and rebased (while branches outside that > namespace can't be deleted / rebased). (Where a git rebase of course is > different from an SVN rebase in that the history becomes liable to be > garbage-collected.) My vote is to allow rebases/deletes in a users/ namespace (and not elsewhere). Segher
Re: GCC Buildbot Update
On Fri, Dec 15, 2017 at 08:42:18AM +0100, Markus Trippelsdorf wrote: > On 2017.12.14 at 21:32 +0100, Christophe Lyon wrote: > > On 14 December 2017 at 09:56, Paulo Matos wrote: > > > I got an email suggesting I add some aarch64 workers so I did: > > > 4 workers from CF (gcc113, gcc114, gcc115 and gcc116); > > > > > Great, I thought the CF machines were reserved for developpers. > > Good news you could add builders on them. > > I don't think this is good news at all. > > Once a buildbot runs on a CF machine it immediately becomes impossible > to do any meaningful measurement on that machine. That is mainly because > of the random I/O (untar, rm -fr, etc.) of the bot. As a result variance > goes to the roof and all measurements drown in noise. Automated runs should not use an unreasonable amount of resources (and neither should manual runs, but the bar for automated things lies much lower, since they are more annoying). All the cfarm machines are shared resources. Benchmarking on them will not work no matter what. And being a shared resource means all users have to share and be mindful of others. > So it would be good if there was a strict separation of machines used > for bots and machines used by humans. In other words bots should only > run on dedicated machines. The aarch64 builds should probably not use all of gcc113..gcc116. We do not have enough resources to dedicate machines to bots. Segher
