Re: testsuite results from master

* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 12:19:00AM CET: > On Sunday 14 November 2010, Ralf Wildenhues wrote: > > I think it is time to reevaluate some of the work that has been done in > > the last few weeks. > Do you mean "go and fix the newly introduced regressions before doing > other

Re: [PATCH] {maint} Improve and extend tests on de-ansification support.

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 10:59:22AM CEST: > > But since we are at it, we can do better, extending coverage and > > making existing tests more "semantic". See the attached patch (for > > maint). > > ans

[PATCH] tests/yaccdry.test ($required): Require bison. (was: Re: More problems with `make -n' in automake-generated rules.)

I'm seeing this failure in test yaccdry.test at the Hydra continuous build system for automake: > FAIL: yaccdry.test (exit: 2) > > /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests

Testsuite failures on IRIX 6.5 (was: testsuite results from master)

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

Re: Testsuite failures on Tru64 OSF 5.1

On Monday 15 November 2010, Peter Rosin wrote: > Running MSVC on osfX.Y is not interesting. I'd write a patch to skip > the test Yeah, I agree this is the best option. > but I can't then test the result. Me neither (I don't have access to a True64/OSF system). > So I won't... Neither will I ;-)

Re: Testsuite failures on Tru64 OSF 5.1

Den 2010-11-14 23:00 skrev Stefano Lattarini: > On Sunday 14 November 2010, Ralf Wildenhues wrote: >> Hello Stefano, >> >> I think it is time to reevaluate some of the work that has been done in >> the last few weeks. I'd like to ask you to postpone pushes of pending >> stuff that has a clock tick

Testsuite results on FreeBSD 6.4 on i386 (was: testsuite results from master)

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

Testsuite failures on HP-UX 11.23 (was: Re: testsuite results from master)

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

Re: testsuite results from master

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. Do you mean "go and fix the newly introduced regressions before doing other testsuite work", or "reconsider the advisability of doin

Re: testsuite results from master

Please disregard; answer to the message "Testsuite failures on Solaris 2.10 on SPARC" instead. Sorry for the noise, Stefano

Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results from master)

[Reposting with a better subject. Sorry for the noise.] On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock

Testsuite failures on Tru64 OSF 5.1 (was: testsuite results from master)

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

Testsuite failures on AIX 5.3 (was: testsuite results from master)

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

Re: testsuite results from master

On Sunday 14 November 2010, Ralf Wildenhues wrote: > Hello Stefano, > > I think it is time to reevaluate some of the work that has been done in > the last few weeks. I'd like to ask you to postpone pushes of pending > stuff that has a clock ticking, and look at the lots of new failures > that a t

testsuite results from master

Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some mi

Re: [PATCH] Enable `set -e' in more tests (plus some tweakings).

* Stefano Lattarini wrote on Thu, Nov 11, 2010 at 03:52:39PM CET: > Pinging this patch again, following this: > Patch is OK. I didn't check whether any of the tests contained constructs problematic for set -e. > I'll wai

Re: [PATCH] {maint} Improve and extend tests on de-ansification support.

Hi Stefano, * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 10:59:22AM CEST: > But since we are at it, we can do better, extending coverage and > making existing tests more "semantic". See the attached patch (for > maint). ansi2knr is a really dying (and ugly) feature; when have we last seen

[PATCHES] {master} Optimize tests `instspc-*.test' for speed.

Finally, here it is the promised patch optimizing the `instspc-*.test' tests for speed, as suggested by Ralf in a previous thread: This patch seems to truly improve the speed of the affected tests, at least according to th

More stable configure output from sanity check.

With the optimized sanity check that only sleeps sometimes (and if not, then sometimes near the end of configure), currently the configure output may change from one run to the other, depending on timing only. The actual semantics are harmless, but since people diff configure output it seems bette

Rebuild menus in the manual.

I'm committing this to maint, and merging to branch-1.11 and master. Thanks, Ralf Rebuild menus in the manual. * doc/automake.texi: Rebuild menus (using ^C ^U ^A in emacs). Thanks to Ian Lance Taylor for the suggestion. diff --git a/doc/automake.texi b/doc/automake.texi index 79

Re: [PATCH 2/3] aclocal: remove @automake_includes

On 11/14/2010 05:46 PM, Ralf Wildenhues wrote: Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: This patch simplifies the overly complicated rules for ACLOCAL_PATH vs. @automake_includes and @system_includes, by stating that ACLOCAL_PATH will override even @automake_inclu

Re: Fix install-strip when $(STRIP) contains several words.

* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:25:02PM CET: > Fix install-strip when $(STRIP) contains several words. > > * lib/am/install.am (install-strip): Update comment. Use > separate sub-make invocations for empty and nonempty $(STRIP), > to fix quoting issues. >

tests: work around dash quoting issue in case statements.

Apparently, dash 0.5.5.1 has some problems with avoiding expansion in case patterns when unusual characters are involved. I'm committing the following patch to maint to let these tests PASS instead of SKIP with this shell. Thanks, Ralf tests: work around dash quoting issue in case statements

Re: [PATCH 2/3] aclocal: remove @automake_includes

Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: > This patch simplifies the overly complicated rules for ACLOCAL_PATH > vs. @automake_includes and @system_includes, by stating that > ACLOCAL_PATH will override even @automake_includes. The simplest > way to achieve this is

Re: User extensions

On Sunday 14 November 2010, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: > > But it's not like I have a "silver bullet" to write proper tests > > which attain complete branch coverage; I just proceed by "common > > sense", trying to maximize such covera

Re: User extensions

* Stefano Lattarini wrote on Sun, Nov 14, 2010 at 01:36:16PM CET: > But it's not like I have a "silver bullet" to write proper tests > which attain complete branch coverage; I just proceed by "common > sense", trying to maximize such coverage. That's all, sadly. A while ago I posted instructions

[PATCH] {master} Extend and improve tests on DejaGnu support.

Another testsuite patch, based off of maint, but to be merged in master only. I will wait the customary 72 hours before pushing. Regards, Stefano -*-*-*- Extend and improve tests on DejaGnu support. * tests/dejagnu.test: Do not create useless dummy test script. Add trailing `:' command. In

Re: User extensions

Hello Pippijn. On Saturday 13 November 2010, Pippijn van wrote: > On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: > > Ideally, I would like to see testsuite coverage for each code path > > ("branch coverage") for new code. I understand that only Stefano is > > able to produce thi