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

[Jeffrey A Law]

  In message < 199709262336.TAA13364@rabi.phys.columbia.edu >you write:
  > >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.
Maybe, maybe not.  I'd have to know more details.

I suspect that if you try to open a new connection, regardles of
whether or not you've logged out that it will take a long time.
Your existing session may be a little more responsive simply because
you're still using it and it may not be as aggressively paged out
to make memory available while building those files.

  > *nod* I presume you already know this is (near-) infinite recursion in
  > extract_bitfield() ?
Yup.  We tried to address it a while back, but it caused some bad
interactions with the g77 front end.  We'll revisit this problem
again later.

  > Well, if it doesn't get deleted, please make it a configure option.  The
  > compiler is big enough already.
I'm pretty confident that it'll get nuked.

While I think gcc is big, it's nowhere near the size of many other
compilers (that interestingly enough compile code faster and produce
faster executing code than gcc) -- for example the HP compiler:

text    data    bss     dec     hex     filename
6207879 377592  457344  7042815 6b76ff  ccom

That's _big_.  Note that is real code & data -- no debug symbols
in that puppy!

  [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.]
You might be interested in --disable-multilib -- it's a configure
option that simply disables multilibs.

If you come up with a scheme to improve multilib, submit it.  We're
more than open to schemes to improve multilib.

Jeff