970917 on mips-sgi-irix6.2, haifa disabled: many problems
Zack Weinberg
zack@rabi.phys.columbia.edu
Sun Sep 21 17:03:00 GMT 1997
I have noticed many problems compiling and testing egcs-970917 on an
Irix 6.2 system.
First, the test summaries:
WARNING: Couldn't find the global config file.
Test Run By zack on Sun Sep 21 15:08:49 1997
Native configuration is mips-sgi-irix6.2
Using /pkg/egcs/bin/../share/dejagnu/baseboards/unix.exp as board
description file for target.
Using /pkg/egcs/bin/../share/dejagnu/config/unix.exp as generic
interface file for target.
/pkg/egcs/egcs-970917/build/gcc/xgcc version egcs-2.90.08 970917
(gcc2-970802 experimental)
=== libio Summary ===
# of expected passes 40
=== libstdc++ Summary ===
# of expected passes 26
# of unexpected failures 2
# of expected failures 2
=== gcc Summary ===
# of expected passes 4805
# of unexpected failures 57
# of expected failures 4
# of untested testcases 17
# of unsupported tests 7
=== g++ Summary ===
# of expected passes 3307
# of unexpected failures 10
# of unexpected successes 1
# of expected failures 86
# of untested testcases 6
For the C compiler the failures fall into three categories:
1) xgcc: Internal compiler error: program cc1 got fatal signal 11
This only happens for c-torture/compile/961203-1.c, and appears to be
linked to kernel messages like this:
WARNING: Process [cc1] pid 17809 killed: process or stack limit exceeded
dks0d1s0: Process [cc1] ran out of disk space
The machine is tight for disk space, but not for memory (64 megs real
RAM and 200 megs of swap), and there are no rlimits. Happens
irrespective of optimization level.
2) dwarf2out.c:1073: failed assertion `cfa_store_reg == STACK_POINTER_REGNUM'
xgcc: Internal compiler error: program cc1 got fatal signal 6
This accounts for most of the failures:
compile/920723-1.c
compile/920501-4.c
compile/920501-12.c
execute/920410-1.c compilation
execute/921113-1.c compilation
execute/921208-2.c compilation
execute/930106-1.c compilation
execute/memcpy-1.c compilation
unsorted/memtst.c
unsorted/msp.c
unsorted/bcopy.c
This happens irrespective of optimization level.
3) Internal error--insn does not satisfy its constraints:
(insn 31 32 4 (set (reg:DF 35 $f3)
(reg:DF 84)) 193 {movdf_internal1} (nil)
(nil))
xgcc: Internal compiler error: program cc1 got fatal signal 6
FAIL: gcc.c-torture/execute/961223-1.c compilation, -O0
It passes with optimization on.
One of the C++ unexpected failures is the `cfa_store_reg' assertion
failure again (g++.jason/mangle3.C). I notice that the execution test
for this case gets an XFAIL -- shouldn't that be UNTESTED?
The others don't get compiler messages. I'll just list them:
FAIL: g++.jason/operator.C overloaded (test for errors, line 13)
FAIL: g++.jason/operator.C overloaded (test for errors, line 14)
FAIL: g++.jason/template31.C (test for excess errors)
FAIL: g++.mike/eh16.C Execution test
FAIL: g++.mike/eh17.C Execution test
FAIL: g++.mike/p710.C previous declaration as.* (test for errors, line 32)
FAIL: g++.mike/p710.C .B::operator.*overloaded (test for errors, line 35)
FAIL: g++.mike/p9732b.C Execution test
FAIL: g++.pt/t28.C (test for excess errors)
The failures in libstdc++ are bizarre:
FAIL: tmap.cc -O execution
XFAIL: tmap.cc -O output
FAIL: tcomplex.cc -O execution
XFAIL: tcomplex.cc -O output
tmap.cc executes just fine when I run it by hand, as does
tcomplex.cc. I got a core dump from tcomplex as executed by the
testsuite, so maybe it's an environment thing. Again, shouldn't those
XFAILs be UNTESTEDs?
I got a core dump (of `a.out') and a stray object file
(920717-x.o) in gcc/testsuite.
----
I also noticed a number of problems with the build:
1) `make bootstrap' decided once that ranlib was necessary (it isn't),
which caused the build to blow up in gcc/f/runtime/libE77. [The
initial `configure' got it right.]
2) Twice I got the machine into a state where it was impossible to log
in either locally or over the network by running a build in a detached
`screen' session -- once it was in `make bootstrap', once in `make
check'. I have no idea how it happened, there was nothing in syslog
or the make log to indicate any trouble; but I had to hard-boot the
machine.
3) If you do `make LANGUAGES=c' in the gcc subdir, it runs configure
for the Fortran runtime anyway.
4) `make bootstrap' compiles all the front ends and the Fortran
runtime at stage 2. Is this intentional?
5) configure forces the use of `cc -32 -O0' for stage 1. This setting
generates pessimal code.
6) All the *out.c files are compiled even though only dwarf2 is
relevant to this platform.
7) It would be nice if the bytecode stuff could be turned off.
8) The various generated files are regenerated at every stage of the
build. Is this intentional?
9) At one point (genattrtab) the Makefile is compared to the .md
file. This seems odd to me.
10) If you configure at the top level, do a manual 3-stage in the gcc
directory, go back to the top and reconfigure with CC set to the
just-built compiler, and then do a make from the top, it recompiles
some things in the gcc directory (cpp, libgcc.a, and a few generated
files, IIRC).
11) I get many "subscript has type `char'" warnings in the Fortran
subdirectory, and one "unused parameter `v'" (for f/com.c).
12) I get many linker warnings about libstdc++ and libm not being used
from the g++ test suite. In the libstdc++ test suite I get warnings
about multiply defined weak symbols.
13) Why are all the test cases in gcc.dg unsupported on this platform?
Except for the dll-* stuff they look quite generic.
System information:
Indy R5k. IRIX 6.2 with recommended patches. The system compilers are from
the 7.1 release, but SGI froze `cc -32' after the 6.2 release. Vendor as
and ld; I couldn't find a binutils release that supports irix6. [I hope
it's in the works; it would be helpful to many if you didn't have to buy the
IDO to get a compiler on SGIs.] dejagnu 970907. Configured in a subdir of
the source directory, with an odd --prefix setting (../configure
--prefix=/pkg/egcs --verbose --disable-haifa), manually 3-staged in gcc/
with LANGUAGES=c each time, and then reconfigured with
CC="/pkg/egcs/egcs-970917/build/gcc/xgcc
-B/pkg/egcs/egcs-970917/build/gcc/stage2/" CFLAGS="-g -O2" and did a
full make from the top. It passes `make compare' for LANGUAGES=c.
Let me know if you want any more information.
I'm not on the mailing list.
zw
p.s. Is there any way to run only a subset of the test suite with
verbose on?
More information about the Gcc-bugs
mailing list