Major testsuite regressions on i386 configurations

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

As can be seen by comparing

	http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00380.html
and
	http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00421.html

between

-LAST_UPDATED: Fri May 10 20:52:18 GMT 2002
+LAST_UPDATED: Sat May 11 20:51:57 GMT 2002

the i386-unknown-freebsd5.0 configuration developed many additional
testsuite failures.  I observe the same thing on i386-pc-solaris2.8.
Almost all new failures are in -Os tests, as can be seen in the excerpt
below:

 		=== g77 tests ===
 
 
 Running target unix/-pthread
+FAIL: g77.f-torture/compile/19990826-3.f,  -Os  
+FAIL: g77.f-torture/compile/980310-3.f,  -Os  
+FAIL: g77.f-torture/compile/20020307-1.f,  -Os  
+FAIL: g77.f-torture/execute/19990325-0.f compilation,  -Os 
+FAIL: g77.f-torture/execute/19990325-1.f compilation,  -Os 
 FAIL: g77.f-torture/execute/6367.f execution,  -O0 
 FAIL: g77.f-torture/execute/6367.f execution,  -O1 
 FAIL: g77.f-torture/execute/6367.f execution,  -O2 

e.g. in g77.f-torture/compile/20020307-1.f, f771 SEGVs:

gdb shows

Program received signal SIGSEGV, Segmentation fault.
0x08215989 in ggc_alloc (size=12) at /vol/gnu/src/gcc/gcc/gcc/ggc-page.c:857
(gdb) where
#0  0x08215989 in ggc_alloc (size=12)
    at /vol/gnu/src/gcc/gcc/gcc/ggc-page.c:857
#1  0x0814bcad in gen_rtx_fmt_ei (code=SUBREG, mode=SImode, arg0=0x96fc9c0, 
    arg1=0) at genrtl.c:675
#2  0x080fab1d in gen_rtx_SUBREG (mode=SImode, reg=0x96fc9c0, offset=0)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:604
#3  0x081ed97d in simplify_subreg (outermode=SImode, op=0x96fc9c0, 
    innermode=QImode, byte=0) at /vol/gnu/src/gcc/gcc/gcc/simplify-rtx.c:2428
#4  0x081edd1d in simplify_gen_subreg (outermode=SImode, op=0x96fc9c0, 
    innermode=QImode, byte=0) at /vol/gnu/src/gcc/gcc/gcc/simplify-rtx.c:2508
#5  0x080fb387 in gen_lowpart_common (mode=SImode, x=0x96fc9c0)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:1003
#6  0x080fb48e in gen_lowpart (mode=SImode, x=0x96fc9c0)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:1211
#7  0x08164fed in gen_split_1391 (operands=0x844b7e0) at insn-emit.c:20279
#8  0x080fdd95 in try_split (pat=0x96fca00, trial=0x84df860, last=1)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:3108
#9  0x080fde07 in try_split (pat=0x96fc9a0, trial=0x84df860, last=1)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:3248
#10 0x080fde07 in try_split (pat=0x96fc940, trial=0x84df860, last=1)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:3248
#11 0x080fde07 in try_split (pat=0x96fc8e0, trial=0x84df860, last=1)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:3248
#12 0x080fde07 in try_split (pat=0x96fc880, trial=0x84df860, last=1)
    at /vol/gnu/src/gcc/gcc/gcc/emit-rtl.c:3248

So there seems to be infinite recursion in try_split (I had to abort f771
running under gdb when recursion depth showed 387 levels with no indication
of termination).

	Rainer