sparc-netbsdelf and gcc.c-torture/compile/20001226-1.c

[Jason R Thorpe <thorpej at wasabisystems dot com>]

On Thu, Jul 18, 2002 at 08:16:31AM -0700, Jason R Thorpe wrote:

 > LAST_UPDATED: Wed Jul 17 18:38:12 UTC 2002
 > 
 > Native configuration is sparc-unknown-netbsdelf
 > 

.
.
.

 > 		=== gcc tests ===
 > 
 > 
 > Running target unix
 > WARNING: program timed out.
 > FAIL: gcc.c-torture/compile/20001226-1.c,  -O1  
 > WARNING: program timed out.
 > FAIL: gcc.c-torture/compile/20001226-1.c,  -O2  
 > WARNING: program timed out.
 > FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer  
 > WARNING: program timed out.
 > FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -g  
 > WARNING: program timed out.
 > FAIL: gcc.c-torture/compile/20001226-1.c,  -Os  

I'm curious why I am not seeing these failures in test results posted
for sparc-sun-solaris2.8 and sparc-suse-linux-gnu..

E.g. if you look at:

	http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00515.html

there seems to be one failure for that test:

WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -g

...and if you look at:

	http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00511.html

there are no failures for that test.

Curiously, they do seem to appear for sparc-redhat-linux-gnu, as
shown here:

	http://gcc.gnu.org/ml/gcc-testresults/2002-07/msg00464.html

...it's the inconsistency that troubles me :-)

Now, the machine I'm running the tests on isn't fast by modern standards,
but it's a reasonably zippy Sun4m machine:

total memory = 127 MB
avail memory = 114 MB
using 896 buffers containing 6616 KB of memory
bootpath: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0
mainbus0 (root): SUNW,SPARCstation-20
cpu0 at mainbus0: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled

I ran the test by hand to see how long it would take -- after running for
about 10 minutes:

ss20-1:thorpej 35$ /usr/local/gnu/bin/gcc -O1 -S 20001226-1.c                  
gcc: Internal error: Illegal instruction (program cc1)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
ss20-1:thorpej 36$  

...which is an indicatation that it blew its stack (SIGILL is what is
forced down a program's throat if the stack frame can't be built for
signal delivery).

GDB seems to confirm this:

ss20-1:thorpej 53$ gdb ./cc1 ./cc1.core
GNU gdb 5.0nb1
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc--netbsdelf"...
Core was generated by `cc1'.
Program terminated with signal 4, Illegal instruction.
Couldn't read input and local registers from stack
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Reading symbols from /usr/lib/libintl.so.0...done.
Loaded symbols for /usr/lib/libintl.so.0
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
#0  ggc_mark_rtx_children_1 (r=0x0) at ../../../gcc/gcc/ggc-common.c:177
177     {
Breakpoint 1 at 0xa3174: file ../../../gcc/gcc/diagnostic.c, line 1364.
Breakpoint 2 at 0x10317050
Breakpoint 3 at 0x1031806c
(gdb) where
#0  ggc_mark_rtx_children_1 (r=0x0) at ../../../gcc/gcc/ggc-common.c:177
Cannot access memory at address 0xeff7fd88
(gdb) 

The default stack limit is 512K on my machine.  I've increased it to 4M
to run the test again ("...still going...", and it looks like it was
able to complete this time with a 4M stack limit, but it certainly took
longer than the 300 seconds allowed by dejagnu).

I am curious about the environment that other people have when running
this test.  I suspect it's really just an issue of "bug is masked by
the testing environment that most people have".

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>