On 29/01/18 15:19, David Malcolm wrote:
>>
>> Hi,
>>
>> I am looking at this today and I noticed that having the source file
>> for
>> all recent GCC revisions is costly in terms of time (if we wish to
>> compress them) and space (for storage). I was instead thinking that
>> jv
>> could calculate
On Mon, 2018-01-29 at 14:55 +0100, Paulo Matos wrote:
>
> On 24/01/18 20:20, David Malcolm wrote:
> >
> > I've added a new feature to jamais-vu (as of
> > 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test
> > results that merely changed line number.
> >
> > For example, if the
On 24/01/18 20:20, David Malcolm wrote:
>
> I've added a new feature to jamais-vu (as of
> 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test
> results that merely changed line number.
>
> For example, if the old .sum file has a:
>
> PASS: g++.dg/diagnostic/param-type-mismat
On 24/01/18 20:20, David Malcolm wrote:
>
> I've added a new feature to jamais-vu (as of
> 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test
> results that merely changed line number.
>
> For example, if the old .sum file has a:
>
> PASS: g++.dg/diagnostic/param-type-mismat
On Sat, 2017-12-16 at 12:06 +0100, Paulo Matos wrote:
>
> On 15/12/17 15:29, David Malcolm wrote:
> > 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
>
On 20/12/17 12:48, James Greenhalgh wrote:
> On Wed, Dec 20, 2017 at 10:02:45AM +, Paulo Matos wrote:
>>
>>
>> On 20/12/17 10:51, Christophe Lyon wrote:
>>>
>>> The recent fix changed the Makefile and configure script in libatomic.
>>> I guess that if your incremental builds does not run conf
On Wed, Dec 20, 2017 at 10:02:45AM +, Paulo Matos wrote:
>
>
> On 20/12/17 10:51, Christophe Lyon wrote:
> >
> > The recent fix changed the Makefile and configure script in libatomic.
> > I guess that if your incremental builds does not run configure, it's
> > still using old Makefiles, and
On 20 December 2017 at 11:02, Paulo Matos wrote:
>
>
> On 20/12/17 10:51, Christophe Lyon wrote:
>>
>> The recent fix changed the Makefile and configure script in libatomic.
>> I guess that if your incremental builds does not run configure, it's
>> still using old Makefiles, and old options.
>>
>>
On 20/12/17 10:51, Christophe Lyon wrote:
>
> The recent fix changed the Makefile and configure script in libatomic.
> I guess that if your incremental builds does not run configure, it's
> still using old Makefiles, and old options.
>
>
You're right. I guess incremental builds should always c
On 20 December 2017 at 09:31, Paulo Matos wrote:
>
>
> On 15/12/17 10:21, Christophe Lyon wrote:
>> 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
On 15/12/17 10:21, Christophe Lyon wrote:
> 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 thin
On 15/12/17 18:05, Segher Boessenkool wrote:
> 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.
>
Yes, we'll definitely need better machines for benchmarking.
On 15/12/17 15:29, David Malcolm wrote:
> 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
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
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
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
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
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 hav
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
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.
>
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
>
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
On 14 December 2017 at 09:56, Paulo Matos wrote:
> Hello,
>
> Apologies for the delay on the update. It was my plan to do an update on
> a monthly basis but it slipped by a couple of weeks.
>
Hi,
Thanks for the update!
> The current status is:
>
> *Workers:*
>
> - x86_64
>
> 2 workers from CF (
On Thu, 2017-12-14 at 09:56 +0100, Paulo Matos wrote:
> Hello,
>
> Apologies for the delay on the update. It was my plan to do an update
> on
> a monthly basis but it slipped by a couple of weeks.
Thanks for working on this.
> The current status is:
>
> *Workers:*
[...snip...]
> *Builds:*
[.
On Wed, 2017-10-11 at 16:17 +0200, Marc Glisse wrote:
> On Wed, 11 Oct 2017, David Malcolm wrote:
>
> > On Wed, 2017-10-11 at 11:18 +0200, Paulo Matos wrote:
> > >
> > > On 11/10/17 11:15, Christophe Lyon wrote:
> > > >
> > > > You can have a look at
> > > > https://git.linaro.org/toolchain/gcc-
On Tue, 10 Oct 2017, Paulo Matos wrote:
> This is a suggestion. I am keen to have corrections from people who use
> this on a daily basis and/or have a better understanding of each status.
Not mentioning them (oddly I don't see anyone mentioning them)
makes me think you've not looked there so all
On Wed, 11 Oct 2017, Martin Sebor wrote:
> I don't have a strong opinion on the definition of a Regression
> in this context but I would very much like to see status changes
> highlighted in the test results to indicate that something that
There are lots of things that are useful *if* you have so
On Okt 10 2017, Joseph Myers wrote:
> Anything else -> FAIL and new FAILing tests aren't regressions at the
> individual test level, but may be treated as such at the whole testsuite
> level.
An ICE FAIL is a regression, but this is always a new test.
Andreas.
--
Andreas Schwab, SUSE Labs,
PASS -> ANY ; Test moves away from PASS
No, only a regression if the destination result is FAIL (if it's
UNRESOLVED then there might be a separate regression - execution test
becoming UNRESOLVED should be accompanied by compilation becoming FAIL).
If it's XFAIL, it might formally
On Wed, 11 Oct 2017, David Malcolm wrote:
On Wed, 2017-10-11 at 11:18 +0200, Paulo Matos wrote:
On 11/10/17 11:15, Christophe Lyon wrote:
You can have a look at
https://git.linaro.org/toolchain/gcc-compare-results.git/
where compare_tests is a patched version of the contrib/ script,
it calls
On Wed, 11 Oct 2017, Christophe Lyon wrote:
> * {PASS,UNSUPPORTED,UNTESTED,UNRESOLVED}-> XPASS
I don't think any of these should be considered regressions. It's good if
someone manually checks anything that's *consistently* XPASSing, to see if
the XFAIL should be removed or restricted to narro
On Wed, 11 Oct 2017, Paulo Matos wrote:
> On 10/10/17 23:25, Joseph Myers wrote:
> > On Tue, 10 Oct 2017, Paulo Matos wrote:
> >
> >> new test -> FAIL; New test starts as fail
> >
> > No, that's not a regression, but you might want to treat it as one (in the
> > sense that it's a re
On Wed, 2017-10-11 at 11:18 +0200, Paulo Matos wrote:
>
> On 11/10/17 11:15, Christophe Lyon wrote:
> >
> > You can have a look at
> > https://git.linaro.org/toolchain/gcc-compare-results.git/
> > where compare_tests is a patched version of the contrib/ script,
> > it calls the main perl script (
On 11 October 2017 at 07:34, Paulo Matos wrote:
> When someone adds a new test to the testsuite, isn't it supposed to not
> FAIL?
Yes, but sometimes it FAILs because the test is using a new feature
that only works on some targets, and the new test was missing the
right directives to make it UNSUPP
On 11/10/17 11:15, Christophe Lyon wrote:
>
> You can have a look at
> https://git.linaro.org/toolchain/gcc-compare-results.git/
> where compare_tests is a patched version of the contrib/ script,
> it calls the main perl script (which is not the prettiest thing :-)
>
Thanks, that's useful. I w
On 11 October 2017 at 11:03, Paulo Matos wrote:
>
>
> On 11/10/17 10:35, Christophe Lyon wrote:
>>
>> FWIW, we consider regressions:
>> * any->FAIL because we don't want such a regression at the whole testsuite
>> level
>> * any->UNRESOLVED for the same reason
>> * {PASS,UNSUPPORTED,UNTESTED,UNRE
On 11/10/17 10:35, Christophe Lyon wrote:
>
> FWIW, we consider regressions:
> * any->FAIL because we don't want such a regression at the whole testsuite
> level
> * any->UNRESOLVED for the same reason
> * {PASS,UNSUPPORTED,UNTESTED,UNRESOLVED}-> XPASS
> * new XPASS
> * XFAIL disappears (may me
On 11 October 2017 at 08:34, Paulo Matos wrote:
>
>
> On 10/10/17 23:25, Joseph Myers wrote:
>> On Tue, 10 Oct 2017, Paulo Matos wrote:
>>
>>> new test -> FAIL; New test starts as fail
>>
>> No, that's not a regression, but you might want to treat it as one (in the
>> sense that it's a
On 2017.10.11 at 08:22 +0200, Paulo Matos wrote:
>
>
> On 11/10/17 06:17, Markus Trippelsdorf wrote:
> > On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
> >> Hi all,
> >>
> >> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update:
> >>
> >> * 3 x86_64 workers from CF are now
On 10/10/17 23:25, Joseph Myers wrote:
> On Tue, 10 Oct 2017, Paulo Matos wrote:
>
>> new test -> FAIL; New test starts as fail
>
> No, that's not a regression, but you might want to treat it as one (in the
> sense that it's a regression at the higher level of "testsuite run should
On 11/10/17 06:17, Markus Trippelsdorf wrote:
> On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
>> Hi all,
>>
>> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update:
>>
>> * 3 x86_64 workers from CF are now installed;
>> * There's one scheduler for trunk doing fresh builds
On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
> Hi all,
>
> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update:
>
> * 3 x86_64 workers from CF are now installed;
> * There's one scheduler for trunk doing fresh builds for every Daily bump;
> * One scheduler doing incremen
On Tue, 10 Oct 2017, Paulo Matos wrote:
> ANY -> no test ; Test disappears
No, that's not a regression. Simply adding a line to a testcase will
change the line number that appears in the PASS / FAIL line for an
individual assertion therein. Or the names will change when e.g.
-std=c++2a
On 26/09/17 10:43, Martin Liška wrote:
> On 09/25/2017 02:49 PM, Paulo Matos wrote:
>> For benchmarks like Qt, blitz (as mentioned in the gcc testing page), we
>> can plot the build time of the benchmark and resulting size when
>> compiling for size.
>>
>
> Please consider using LNT:
> http://ll
On 09/25/2017 02:49 PM, Paulo Matos wrote:
> For benchmarks like Qt, blitz (as mentioned in the gcc testing page), we
> can plot the build time of the benchmark and resulting size when
> compiling for size.
>
Please consider using LNT:
http://llvm.org/docs/lnt/
Usage:
http://lnt.llvm.org/
I've
On 25/09/17 13:36, Martin Liška wrote:
>
> Would be great, what exactly do you want to visualize? For me, even having
> green/red spots
> works fine in order to quickly identify what builds are wrong.
>
There are several options and I think mostly it depends on what everyone
would like to see
On 25/09/17 13:14, Jonathan Wakely wrote:
> On 25 September 2017 at 11:13, Paulo Matos wrote:
>>> Apart from that, I fully agree with octoploid that
>>> http://toolchain.lug-owl.de/buildbot/ is duplicated effort which is running
>>> on GCC compile farm machines and uses a shell scripts to utiliz
On 09/25/2017 12:13 PM, Paulo Matos wrote:
>
>
> On 25/09/17 11:52, Martin Liška wrote:
>> Hi Paulo.
>>
>> Thank you for working on that! To be honest, I've been running local
>> buildbot on
>> my desktop machine which does builds your buildbot instance can do (please
>> see:
>> https://pastebo
On 25 September 2017 at 11:13, Paulo Matos wrote:
>> Apart from that, I fully agree with octoploid that
>> http://toolchain.lug-owl.de/buildbot/ is duplicated effort which is running
>> on GCC compile farm machines and uses a shell scripts to utilize. I would
>> prefer to integrate it to Buildbot
On 25/09/17 11:52, Martin Liška wrote:
> Hi Paulo.
>
> Thank you for working on that! To be honest, I've been running local buildbot
> on
> my desktop machine which does builds your buildbot instance can do (please
> see:
> https://pasteboard.co/GLZ0vLMu.png):
>
Hi Martin,
Thanks for sharin
Hi Paulo.
Thank you for working on that! To be honest, I've been running local buildbot on
my desktop machine which does builds your buildbot instance can do (please see:
https://pasteboard.co/GLZ0vLMu.png):
- doing time to time (once a week) sanitizer builds: ASAN, UBSAN and run
test-suite
- do
On Fri, 22 Sep 2017, Paulo Matos wrote:
> > Note that even without a simulator (but with target libc), you can test
> > just the compilation parts of the testsuite using a board file with a
> > dummy _load implementation.
> >
>
> I was not aware of that. I will keep that in mind once I try to
On 22/09/17 01:23, Joseph Myers wrote:
> On Thu, 21 Sep 2017, Paulo Matos wrote:
>
>> Interesting suggestion. I haven't had the opportunity to look at the
>> compile farm. However, it could be interesting to have a mix of workers:
>> native compile farm ones and some x86_64 doing cross compilati
On Thu, 21 Sep 2017, Paulo Matos wrote:
> Interesting suggestion. I haven't had the opportunity to look at the
> compile farm. However, it could be interesting to have a mix of workers:
> native compile farm ones and some x86_64 doing cross compilation and
> testing.
Note that even without a simu
On Thu, 21 Sep 2017, Paulo Matos wrote:
> I totally agree that only if people get involved in checking if there
> were regressions and keeping an eye on what's going on are things going
> to improve. The framework can help a lot here by notifying the right
> people and the mailing list if somethin
On 21/09/17 14:18, Christophe Lyon wrote:
>>
>> If this is something of interest, then we will need to understand what
>> is required, among those:
>>
>> - which machines we can use as workers: we certainly need more worker
>> (previously known as slave) machines to test GCC in different
>> archs
On 21/09/17 16:41, Martin Sebor wrote:
>
> The regression and the testresults lists are useful but not nearly
> as much as they could be. For one, the presentation isn't user
> friendly (a matrix view would be much more informative). But even
> beyond it, rather than using the pull model (peop
On 21/09/17 14:11, Mark Wielaard wrote:
> Hi,
>
> First let me say I am also a fan of buildbot. I use it for a couple of
> projects and it is really flexible, low on resources, easy to add new
> builders/workers and easily extensible if you like python.
>
> On Thu, 2017-09-21 at 07:18 +0200, Ma
On 21/09/17 02:27, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Segher Boessenkool wrote:
>
>>> - buildbot can notify people if the build fails or if there's a test
>>> regression. Notification can be sent to IRC and email for example. What
>>> would people prefer to have as the settings for notif
On 21/09/17 01:01, 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 worke
On 20/09/17 19:14, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Paulo Matos wrote:
>
>> - buildbot can notify people if the build fails or if there's a test
>> regression. Notification can be sent to IRC and email for example. What
>> would people prefer to have as the settings for notifications?
On Thu, 21 Sep 2017, Markus Trippelsdorf wrote:
> And it has the basic problem of all automatic testing: that in the long
> run everyone simply ignores it.
Hence, see my comments about the value of having someone who monitors the
results and files bugs / notifies patch authors / fixes issues.
I
On 09/20/2017 11:18 PM, Markus Trippelsdorf wrote:
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
On 20 September 2017 at 17:01, Paulo Matos wrote:
> Hi all,
>
> I am internally running buildbot for a few projects, including one for a
> simple gcc setup for a private port. After some discussions with David
> Edelsohn at the last couple of Cauldrons, who told me this might be
> interesting for
Hi,
First let me say I am also a fan of buildbot. I use it for a couple of
projects and it is really flexible, low on resources, easy to add new
builders/workers and easily extensible if you like python.
On Thu, 2017-09-21 at 07:18 +0200, Markus Trippelsdorf wrote:
> And it has the basic problem
On 20/09/17 17:07, Jeff Law wrote:
> I'd strongly recommend using one of the existing infrastructures. I
> know several folks (myself included) are using Jenkins/Hudson. There's
> little to be gained building a completely new infrastructure to manage a
> buildbot.
>
As David pointed out in an
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 nee
On Wed, 20 Sep 2017, Segher Boessenkool wrote:
> > - buildbot can notify people if the build fails or if there's a test
> > regression. Notification can be sent to IRC and email for example. What
> > would people prefer to have as the settings for notifications?
>
> Just try it! IRC is most usef
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 differ
Hello friends!
On Wed, Sep 20, 2017 at 10:12 AM, David Edelsohn wrote:
> On Wed, Sep 20, 2017 at 11:07 AM, Jeff Law wrote:
>> On 09/20/2017 09:01 AM, Paulo Matos wrote:
>>> Hi all,
>>>
>>> I am internally running buildbot for a few projects, including one for a
>>> simple gcc setup for a private
On Wed, 20 Sep 2017, Paulo Matos wrote:
> - buildbot can notify people if the build fails or if there's a test
> regression. Notification can be sent to IRC and email for example. What
> would people prefer to have as the settings for notifications?
It's very useful if someone reviews regressions
On Wed, Sep 20, 2017 at 11:07 AM, Jeff Law wrote:
> On 09/20/2017 09:01 AM, Paulo Matos wrote:
>> Hi all,
>>
>> I am internally running buildbot for a few projects, including one for a
>> simple gcc setup for a private port. After some discussions with David
>> Edelsohn at the last couple of Cauld
On 09/20/2017 09:01 AM, Paulo Matos wrote:
> Hi all,
>
> I am internally running buildbot for a few projects, including one for a
> simple gcc setup for a private port. After some discussions with David
> Edelsohn at the last couple of Cauldrons, who told me this might be
> interesting for the com
On 01/10/14 10:11, Richard Sandiford wrote:
Hi,
Philippe Baril Lecavalier writes:
I have been experimenting with buildbot lately, and I would be glad to
help in providing it. If there is interest, I could have a prototype and
a detailed proposal ready in a few days. It could serve GCC, binutil
Hi,
Philippe Baril Lecavalier writes:
> I have been experimenting with buildbot lately, and I would be glad to
> help in providing it. If there is interest, I could have a prototype and
> a detailed proposal ready in a few days. It could serve GCC, binutils
> and some important libraries as well.
75 matches
Mail list logo
