gcc-4.6.3 ICE

[Dennis Clarke]

> 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 |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+