--- Comment #29 from janis at gcc dot gnu dot org 2008-12-02 17:49 ---
Fixed in trunk (4.4) and 4.3; 4.2 isn't expected to have additional releases so
I haven't backported it there.
The patch solves the original reported problem, a hard-coded timeout for
libstdc++ tests, by allowing the
--- Comment #28 from janis at gcc dot gnu dot org 2008-12-02 17:45 ---
Subject: Bug 28870
Author: janis
Date: Tue Dec 2 17:44:08 2008
New Revision: 142366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142366
Log:
Backport from mainline:
2008-11-26 Janis Johnso
--- Comment #27 from janis at gcc dot gnu dot org 2008-11-26 22:16 ---
Subject: Bug 28870
Author: janis
Date: Wed Nov 26 22:15:07 2008
New Revision: 142230
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142230
Log:
PR testsuite/28870
* lib/objc.exp (objc_target_c
--- Comment #26 from janis at gcc dot gnu dot org 2008-11-26 18:52 ---
Subject: Bug 28870
Author: janis
Date: Wed Nov 26 18:51:07 2008
New Revision: 142225
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142225
Log:
gcc/
PR testsuite/28870
* doc/sourcebuild.texi (
--- Comment #25 from janis at gcc dot gnu dot org 2008-11-24 22:31 ---
I'm still tweaking this, to support dg-timeout and dg-timeout-factor plus
tool-specific default timeouts for gcc, libstdc++-v3, libgomp, and libmudflap.
As for picking up gcc,timeout for the target board I discovered
--- Comment #24 from janis at gcc dot gnu dot org 2008-11-21 01:28 ---
For the libstdc++ tests, which are the original focus of this PR, is it enough
to provide dg-timeout and dg-timeout-factor and either leave the 600 default,
or else take the larger of that and [target_info gcc,timeout
--- Comment #23 from janis at gcc dot gnu dot org 2008-11-21 00:58 ---
I posted a patch for compiler tests at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01066.html
but after playing around more realized that it shouldn't be necessary to allow
setting a default in .dejagnurc, since
--- Comment #22 from sje at cup dot hp dot com 2008-11-18 23:21 ---
Your plan sounds good to me. I am thinking that using the timeout-factor
on g++.dg/torture/pr31863.C, gcc.c-torture/compile/20001226-1.c, and
gcc.dg/20020425-1.c to deal with the compiler timeouts on these long compile
--- Comment #21 from janis at gcc dot gnu dot org 2008-11-18 22:48 ---
Interesting that you should ask, I modified the patch yesterday and intend to
submit it as soon as I've done some more testing.
The current version adds dg-timeout, which sets the timeout for running the
compiler in
--- Comment #20 from sje at cup dot hp dot com 2008-11-18 22:39 ---
I see there were some patches submitted for this issue
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01098.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00267.html
I get timeouts on my slow hppa system and would be
--- Comment #19 from jsm28 at gcc dot gnu dot org 2008-05-19 20:22 ---
4.2.4 is being released, changing milestones to 4.2.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from nightstrike at gmail dot com 2008-04-06 16:03 ---
What is the status on this? I am having a lot of test timeouts when testing
the x86_64-pc-mingw cross compiler, as sometimes there are slow programd and
annoying ssh network delays. Extending the timeout in a robust
12 matches
Mail list logo
