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:*
[.
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.
The current status is:
*Workers:*
- x86_64
2 workers from CF (gcc16 and gcc20) up and running;
1 worker from my farm (jupiter-F26) up and running;
2 broken CF (
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
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 incremental builds for each active branch;
* An IRC bot which is curren
45 matches
Mail list logo
