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

[Zack Weinberg <zack at rabi dot phys dot columbia dot edu>]

On Tue, 23 Sep 1997 01:48:51 -0600, Jeffrey A Law wrote:

>  > 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.

I *think* the problem here (which still exists in 970924) is that the gcc
Makefile passes the f/runtime configure RANLIB_FOR_TARGET and
RANLIB_TEST_FOR_TARGET, but configure is looking for the unqualified RANLIB
and RANLIB_TEST.  Or at least, this patch makes the problem go away for me:

--- gcc/f/Make-lang.in.970924   Fri Sep 26 18:10:22 1997
+++ gcc/f/Make-lang.in  Fri Sep 26 18:11:05 1997
@@ -56,8 +56,8 @@
        LEXFLAGS="$(LEXFLAGS)" \
        MAKEINFO="$(MAKEINFO)" \
        MAKEINFOFLAGS="$(MAKEINFOFLAGS)" \
-       RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
-       RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \
+       RANLIB="$(RANLIB)" \
+       RANLIB_TEST="$(RANLIB_TEST)" \
        SHELL="$(SHELL)" \
        exec_prefix="$(exec_prefix)" \
        prefix="$(prefix)" \

I don't fully understand the Makefiles, so this may not be correct for
everyone.  Longer term, might I suggest that RANLIB_TEST should go away
and RANLIB be set to : if ranlib is not needed (as determined by configure?)

>  > 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

Odd that it doesn't seem to cause problems when I don't log out.

>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).

*nod* I presume you already know this is (near-) infinite recursion in
extract_bitfield() ?

>  > 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.

Well, if it doesn't get deleted, please make it a configure option.  The
compiler is big enough already.  [Along the same lines, It Would Be Nice if
one could disable various of the multilib targets; for example, I can't use
-mabi=64 code on this beast and would just as soon save the space.]

>  > 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.

I'll check if it still happens with 970924, but SGI's linker tends to emit
warnings about things that aren't really significant -- for example, it
warns whenever -liberty preempts a routine in libc.so.  

I will get back to you on the other stuff as soon as I get a chance to run
the testsuite.  [970924 just passed `make compare' and I have to leave now.]
Sorry for the long delay in the reply, we had a crisis earlier this week
and I had no time to do any tests.

zw