Patchwork Go testsuite patch committed: Load timeout.exp

login
register
mail settings
Submitter Ian Taylor
Date Feb. 9, 2013, 1:54 a.m.
Message ID <mcra9re8d64.fsf@google.com>
Download mbox | patch
Permalink /patch/219360/
State New
Headers show

Comments

Ian Taylor - Feb. 9, 2013, 1:54 a.m.
Since testsuite/lib/go.exp now uses [timeout_value], it needs to load
timeout.exp.  This shows up when testing libgo using DejaGNU.
Bootstrapped and ran Go tests on x86_64-unknown-linux-gnu.  Committed to
mainline.

Ian


2013-02-08  Ian Lance Taylor  <iant@google.com>

	* lib/go.exp: Load timeout.exp.
Andreas Schwab - Feb. 9, 2013, 11:18 a.m.
Ian Lance Taylor <iant@google.com> writes:

> 2013-02-08  Ian Lance Taylor  <iant@google.com>
>
> 	* lib/go.exp: Load timeout.exp.

ERROR: Couldn't find library file timeout.exp.

Andreas.
Ian Taylor - Feb. 9, 2013, 6:24 p.m.
On Sat, Feb 9, 2013 at 3:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Ian Lance Taylor <iant@google.com> writes:
>
>> 2013-02-08  Ian Lance Taylor  <iant@google.com>
>>
>>       * lib/go.exp: Load timeout.exp.
>
> ERROR: Couldn't find library file timeout.exp.

Sorry, I was told on IRC that the patch worked.

As I mentioned on the bug, can you figure out why it fails?  The file
gcc/testsuite/lib/go.exp does a load_lib of several files from that
directory.  Why would they all work but loading timeout.exp fails?

Ian
Matthias Klose - Feb. 18, 2013, 8:23 a.m.
Am 09.02.2013 19:24, schrieb Ian Lance Taylor:
> On Sat, Feb 9, 2013 at 3:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Ian Lance Taylor <iant@google.com> writes:
>>
>>> 2013-02-08  Ian Lance Taylor  <iant@google.com>
>>>
>>>       * lib/go.exp: Load timeout.exp.
>>
>> ERROR: Couldn't find library file timeout.exp.
> 
> Sorry, I was told on IRC that the patch worked.

yes, it did work for me, but I only tested the default multilib location.

> As I mentioned on the bug, can you figure out why it fails?  The file
> gcc/testsuite/lib/go.exp does a load_lib of several files from that
> directory.  Why would they all work but loading timeout.exp fails?

but as I see now, it seems to fail for the non-default multilib locations. Is
there a somewhere a missing .. in a path?

the libgo testsuite unfortunately works not as all other testsuite for the
libraries do work. Usually if you do want to test a multilib build, you call

  RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check

and only the check target for the default multilib is called. libgo however
descends into the non-default multilib targets and calls check there too. And
then with the above RUNTESTFLAGS, every go test is called nine times instead of
three times, and apparently fails the other six times.

Please let libgo behave the same as the other target libraries for the check
target, even it does introduce some delta.

Maybe this is seen on m68k too, because it's a multilib configuration too?

  Matthias
Ian Taylor - Feb. 18, 2013, 7:07 p.m.
On Mon, Feb 18, 2013 at 12:23 AM, Matthias Klose <doko@ubuntu.com> wrote:
>
>> As I mentioned on the bug, can you figure out why it fails?  The file
>> gcc/testsuite/lib/go.exp does a load_lib of several files from that
>> directory.  Why would they all work but loading timeout.exp fails?
>
> but as I see now, it seems to fail for the non-default multilib locations. Is
> there a somewhere a missing .. in a path?

I thought this was fixed now by a patch to
libgo/testsuite/lib/libgo.exp.  Are you still seeing trouble with
current mainline?


> the libgo testsuite unfortunately works not as all other testsuite for the
> libraries do work. Usually if you do want to test a multilib build, you call
>
>   RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check
>
> and only the check target for the default multilib is called. libgo however
> descends into the non-default multilib targets and calls check there too. And
> then with the above RUNTESTFLAGS, every go test is called nine times instead of
> three times, and apparently fails the other six times.
>
> Please let libgo behave the same as the other target libraries for the check
> target, even it does introduce some delta.

I can't remember if there is a bug report open for this or not.

Ian
Matthias Klose - Feb. 23, 2013, 2:56 a.m.
Am 18.02.2013 20:07, schrieb Ian Lance Taylor:
>> the libgo testsuite unfortunately works not as all other testsuite for the
>> > libraries do work. Usually if you do want to test a multilib build, you call
>> >
>> >   RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check
>> >
>> > and only the check target for the default multilib is called. libgo however
>> > descends into the non-default multilib targets and calls check there too. And
>> > then with the above RUNTESTFLAGS, every go test is called nine times instead of
>> > three times, and apparently fails the other six times.
>> >
>> > Please let libgo behave the same as the other target libraries for the check
>> > target, even it does introduce some delta.
> I can't remember if there is a bug report open for this or not.

this is now PR go/56432.

Patch

Index: lib/go.exp
===================================================================
--- lib/go.exp	(revision 195909)
+++ lib/go.exp	(working copy)
@@ -19,6 +19,7 @@ 
 #
 load_lib prune.exp
 load_lib gcc-defs.exp
+load_lib timeout.exp
 load_lib target-libpath.exp
 
 #