egcs-980321 on sparc-sun-solaris2.5.1 test results

egcs-980321 on sparc-sun-solaris2.5.1 test results

[Horst von Brand]

--enable-{shared,haifa,threads}
{C,CXX,F77}FLAGS = -O2 -fomit-frame-pointer

Note that I killed the first loop-2c.c compilation that FAILed after some
98 CPU minutes (left the machine for lunch :) and the second one after some
3 CPU minutes. Isn't there a way to limit the running time of any
compilation/execution to something like 10 minutes to catch infinite loops?

WARNING: Couldn't find the global config file.
Test Run By broot on Tue Mar 24 02:28:46 1998
Native configuration is sparc-sun-solaris2.5.1

		=== libio tests ===

		=== libio Summary ===

# of expected passes		40

WARNING: Couldn't find the global config file.
Test Run By broot on Tue Mar 24 02:32:23 1998
Native configuration is sparc-sun-solaris2.5.1

		=== libstdc++ tests ===

FAIL: tmap.cc compilation
FAIL: tmap.cc -O compilation

		=== libstdc++ Summary ===

# of expected passes		24
# of unexpected failures	2
# of expected failures		4

WARNING: Couldn't find the global config file.
Test Run By broot on Tue Mar 24 02:35:58 1998
Native configuration is sparc-sun-solaris2.5.1

		=== gcc tests ===

FAIL: gcc.c-torture/execute/loop-2c.c compilation,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2c.c compilation,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/loop-2d.c compilation,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2d.c compilation,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -g 

		=== gcc Summary ===

# of expected passes		5994
# of unexpected failures	9
# of expected failures		6
# of untested testcases		4
# of unsupported tests		11

WARNING: Couldn't find the global config file.
Test Run By broot on Tue Mar 24 06:09:03 1998
Native configuration is sparc-sun-solaris2.5.1

		=== g++ tests ===

FAIL: g++.brendan/crash8.C (test for excess errors)
XPASS: g++.mike/ns3.C  (test for errors, line 1)
FAIL: g++.other/friend1.C (test for excess errors)
FAIL: g++.pt/explicit12.C (test for excess errors)
FAIL: g++.pt/explicit13.C (test for excess errors)
FAIL: g++.pt/memclass7.C (test for excess errors)
FAIL: g++.pt/spec10.C (test for excess errors)
FAIL: g++.pt/spec11.C (test for excess errors)
FAIL: g++.pt/spec12.C (test for excess errors)
FAIL: g++.pt/spec13.C (test for excess errors)
FAIL: g++.pt/spec15.C (test for excess errors)
FAIL: g++.pt/spec6.C no matching function (test for errors, line 25)
FAIL: g++.pt/spec6.C no matching function (test for errors, line 28)
FAIL: g++.pt/spec6.C (test for excess errors)
FAIL: g++.pt/vaarg.C  Execution test

		=== g++ Summary ===

# of expected passes		3725
# of unexpected failures	14
# of unexpected successes	1
# of expected failures		80
# of untested testcases		6

WARNING: Couldn't find the global config file.
Test Run By broot on Tue Mar 24 07:24:10 1998
Native configuration is sparc-sun-solaris2.5.1

		=== g77 tests ===

		=== g77 Summary ===

# of expected passes		168

Re: egcs-980321 on sparc-sun-solaris2.5.1 test results

[Robert Lipe]

> 3 CPU minutes. Isn't there a way to limit the running time of any
> compilation/execution to something like 10 minutes to catch infinite loops?

Run the programs under a shell that supports limit control.  Under
Solaris, I think this means ksh.   Then use the shell's internal ulimit
to cap the max CPU time or stack or vm or anything else you need to
catch.

Don't fall for the trick of looking at the man page for ulimit(1) to find
the syntax.  Look at the man page for ksh to find it.

RJL

Re: egcs-980321 on sparc-sun-solaris2.5.1 test results

[Robert Lipe]

> > Run the programs under a shell that supports limit control.  Under
> 
> That's something dejagnu would have to do for each compilation/execution.

No, it's something inherited for all the children of the shell.   I solve
this by having my korn shell script that calls runtest invoke ulimit before
doing so.

I had to work this out becuase one of the tests used to cause recursion
and OpenServer handled this very poorly.   So I capped the stack size to
stop it from tormenting the system.

RJL

Re: egcs-980321 on sparc-sun-solaris2.5.1 test results

[Horst von Brand]

Robert Lipe <robertl@dgii.com> said:
> In-Reply-To: < 199803250454.AAA03172@pincoya.inf.utfsm.cl >; from Horst von Brand
>      *** on Wed, Mar 25, 1998 at 12:54:37AM -0400

> > 3 CPU minutes. Isn't there a way to limit the running time of any
> > compilation/execution to something like 10 minutes to catch infinite loops?

> Run the programs under a shell that supports limit control.  Under
> Solaris, I think this means ksh.   Then use the shell's internal ulimit
> to cap the max CPU time or stack or vm or anything else you need to
> catch.

That's something dejagnu would have to do for each compilation/execution.
And if that is done, it's worth doing well, i.e., portably once and for
all. Not being at all familiar with expect and dejagnu, I can't even start
thinking about how to do it, but I'd expect expect to have the means for
doing exactly that on its own. Maybe it is in there, and needs to be
activated with some switch?
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: egcs-980321 on sparc-sun-solaris2.5.1 test results

[Jeffrey A Law]

  In message < 199803260454.AAA06627@pincoya.inf.utfsm.cl >you write:
  > > Run the programs under a shell that supports limit control.  Under
  > > Solaris, I think this means ksh.   Then use the shell's internal ulimit
  > > to cap the max CPU time or stack or vm or anything else you need to
  > > catch.
  > 
  > That's something dejagnu would have to do for each compilation/execution.
  > And if that is done, it's worth doing well, i.e., portably once and for
  > all. Not being at all familiar with expect and dejagnu, I can't even start
  > thinking about how to do it, but I'd expect expect to have the means for
  > doing exactly that on its own. Maybe it is in there, and needs to be
  > activated with some switch?
Dejagnu does have the concept of "timeouts", and I think if you wait
long enough they will kick in :-) 

No, I don't know what the default value is -- I just know that some
of the longer running tests actually do time out when running on
a simulator.  It may be the case that only the simulator testing
harness uses them.  I don't really know.

jeff

Re: egcs-980321 on sparc-sun-solaris2.5.1 test results

[Andreas Schwab]

Robert Lipe <robertl@dgii.com> writes:

|>> > Run the programs under a shell that supports limit control.  Under
|>> 
|>> That's something dejagnu would have to do for each compilation/execution.

|> No, it's something inherited for all the children of the shell.

Except that if you limit CPU time then dejagnu will die as well.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org