public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Go testsuite patch committed: Load timeout.exp
@ 2013-02-09  1:54 Ian Lance Taylor
  2013-02-09 11:18 ` Andreas Schwab
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2013-02-09  1:54 UTC (permalink / raw)
  To: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

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.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 269 bytes --]

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
 
 #

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Go testsuite patch committed: Load timeout.exp
  2013-02-09  1:54 Go testsuite patch committed: Load timeout.exp Ian Lance Taylor
@ 2013-02-09 11:18 ` Andreas Schwab
  2013-02-09 18:24   ` Ian Lance Taylor
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Schwab @ 2013-02-09 11:18 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-patches

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.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Go testsuite patch committed: Load timeout.exp
  2013-02-09 11:18 ` Andreas Schwab
@ 2013-02-09 18:24   ` Ian Lance Taylor
  2013-02-18  8:23     ` Matthias Klose
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2013-02-09 18:24 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: gcc-patches

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Go testsuite patch committed: Load timeout.exp
  2013-02-09 18:24   ` Ian Lance Taylor
@ 2013-02-18  8:23     ` Matthias Klose
  2013-02-18 19:07       ` Ian Lance Taylor
  0 siblings, 1 reply; 6+ messages in thread
From: Matthias Klose @ 2013-02-18  8:23 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Andreas Schwab, gcc-patches

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Go testsuite patch committed: Load timeout.exp
  2013-02-18  8:23     ` Matthias Klose
@ 2013-02-18 19:07       ` Ian Lance Taylor
  2013-02-23  2:57         ` Matthias Klose
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2013-02-18 19:07 UTC (permalink / raw)
  To: Matthias Klose; +Cc: Andreas Schwab, gcc-patches

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Go testsuite patch committed: Load timeout.exp
  2013-02-18 19:07       ` Ian Lance Taylor
@ 2013-02-23  2:57         ` Matthias Klose
  0 siblings, 0 replies; 6+ messages in thread
From: Matthias Klose @ 2013-02-23  2:57 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Andreas Schwab, gcc-patches

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-02-23  2:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-09  1:54 Go testsuite patch committed: Load timeout.exp Ian Lance Taylor
2013-02-09 11:18 ` Andreas Schwab
2013-02-09 18:24   ` Ian Lance Taylor
2013-02-18  8:23     ` Matthias Klose
2013-02-18 19:07       ` Ian Lance Taylor
2013-02-23  2:57         ` Matthias Klose

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).