> On 19 March 2012 14:56, Dennis Clarke wrote: >> >> thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html >> >> === gcc tests === >> >> >> Running target unix >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (internal compiler error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer >> (test for excess errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler >> error) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess >> errors) >> FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler >> error) >> >> >> I'd like to extend my stack size a bit and re-run the gcc tests only. >> At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c >> run >> again. In detail. > > The full output of those tests should still be in a .log file > somewhere under the build dir. > >> What would the procedure for that be ? > > See http://gcc.gnu.org/install/test.html and > http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run > specific tests. > > I think you should be able to do something like: > > make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c >
Thank you for the quick reply. Hrmmmm, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 which is where I see the familiar old friend : titan-i386-SunOS5.8 $ cat ../gcc-4.6.3/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c #define LBR1 ( ( ( ( ( ( ( ( ( ( #define LBR2 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 #define LBR3 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 #define LBR4 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 #define LBR5 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 #define LBR6 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 #define RBR1 ) ) ) ) ) ) ) ) ) ) #define RBR2 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 #define RBR3 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 #define RBR4 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 #define RBR5 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 #define RBR6 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 int q5_var = LBR4 0 RBR4; This really comes down to the users stack size and a ulimit -s X for X=16384 or even 32768 solves it if I recall. I think I may just run the whole testsuite again, there are other pieces of ICE that I'd like to see melt away. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-------------------------+-----------------------------------+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-------------------------+-----------------------------------+
