970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Jeffrey A Law]

  > 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:
This is a known problem.  It can be safely ignored for now.

  > 2) dwarf2out.c:1073: failed assertion `cfa_store_reg == STACK_POINTER_REGNU
  > M'
  > 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
I believe this has been fixed for the next snapshot.

  > 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 
Not sure, we'll have to look further into this.


  > 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?
Yes, but expressing this can be difficult to do with the old-deja.exp
framework.

  > 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.]
We're looking into this.  No solution yet.


  > 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.
Probably while building insn-attrtab.c and insn-attrtab.o during
the make bootstrap -- these take an enormous amount of memory
to build for mips targets

During the make check it was the 961203-1.c testcase which will
suck up every byte of available VM (which will effectively lock
the machine until the compiler dies).

  > 3) If you do `make LANGUAGES=c' in the gcc subdir, it runs configure
  > for the Fortran runtime anyway.
Yes, this is necessary.


  > 4) `make bootstrap' compiles all the front ends and the Fortran
  > runtime at stage 2.  Is this intentional?
Yes.

  > 5) configure forces the use of `cc -32 -O0' for stage 1.  This setting
  > generates pessimal code.
I don't know why it does this.  It might be because cc mis-compiles
things with other options.  I don't really know.  We don't really
care how slow the stage1 compiler runs since it should never get
installed.

  > 6) All the *out.c files are compiled even though only dwarf2 is
  > relevant to this platform.
Yes, this is normal.

  > 7) It would be nice if the bytecode stuff could be turned off.
We're seriously considering just removing it.  It's a poor design,
poor implementation and nobody's ever used it for anything.


  > 8) The various generated files are regenerated at every stage of the
  > build.  Is this intentional?
Yes.  The gen* and insn* stuff will be rebuilt through each stage.

  > 9) At one point (genattrtab) the Makefile is compared to the .md
  > file.  This seems odd to me.
This is how the build process checks for a pre-built insn-attrtab.c
file.  It may seem odd, but it is the way it should work.  This
also happens for other files.

  > 11) I get many "subscript has type `char'" warnings in the Fortran
  > subdirectory, and one "unused parameter `v'" (for f/com.c).
Yes, these warnings can be safely ignored.

  > 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.
This is a problem.

  > 13) Why are all the test cases in gcc.dg unsupported on this platform?
  > Except for the dll-* stuff they look quite generic.
dll tests are in general, difficult to write in a truely generic
manner.

  > I'm not on the mailing list.
I would recommend you get on the mailing list if you plan on using
snapshots in the future.

  > p.s.  Is there any way to run only a subset of the test suite with
  > verbose on?
Not that I'm aware of.  Though it is possible to run subsets of
tests.

ie you can do something like
make check-gcc RUNTESTFLAGS="execute.exp --verbose"

To run just the execute.exp tests.

jeff