Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Jeffrey A Law <law@cygnus.com>]

  In message < 199812022104.NAA03634@rtl.cygnus.com >you write:
  > 	1.  If Irix6 cc is used for stage1, should we add -n32 so when it
  > 	builds libiberty.a it is link compatible with stage2 binaries?
  > 
  > I don't care which choice is used, as long as I can still build gcc.
That is the ultimate goal :-)


  > If we add -n32, people that have old versions of the SGI C compiler won't
  > be able to build egcs anymore.  However, I suspect that few people have
  > these old and buggy SGI C compilers anymore.
We can always have autoconf test for -n32 when building with the native
compiler and fall back to something else.

  > 	2.  Is "cc -n32" support truly buggy, or can we use it?
  > 
  > Every SGI compiler I tried up through 7.0beta had a bug that caused gcc to
  > be miscompiled.  7.0beta had only a single bug, which caused an
  > optimization to be disabled, but did not cause bad code.  Hence if using
  > 7.0beta, a stage2/stage3 comparison would fail, but a stage3/stage4
  > comparison would succeed.  The one bug I reported against 7.0beta was
  > fixed in 7.1.  All versions prior to 7.0beta have serious bugs that can
  > not be worked around easily.
Is there a way to test for specific versions of the SGI compiler?  Do we
even want to worry about beta versions of the SGI compiler?

  > 	3.  If cc is used for stage1, libiberty.a is not optimized, it only
  > 	gets -g passed to it.  Do we care?  (This is a generic problem, not
  > 	an irix6 specific one.)
  > 
  > No, we don't care.
Agreed.  It's in the noise.

  > 	4.  Assuming we go with -n32, why is egcs ignoring the CC setting in
  > 	config/mh-irix6 and how do we fix it?  (This doesn't seem to be Irix6
  > 	specific either.)
As Jim mentioned, the config/mh-* stuff is pretty hokey and needs a rethink.

  > You didn't mention it, but there is also a gcc/config/mips/x-irix6 file
  > which specifies `cc -32'.  This part is from gcc2, and this part broke when gcc2
  > adopted autoconf.  Similarly, I don't think we can make this work anymore
  > without using a different makefile variable.
Right.  And the general though was most of that stuff needs to disappear too.

  > 
  > 	5.  Maybe another way to go is to build libiberty.a for each stage.
  > 	We could build a symlink tree in egcs/gcc/libiberty and move it into
  > 	stageN so it is rebuilt every stage.  This would solve the linking
  > 	problem because libiberty.a would use the same ABI as the binaries it
  > 	is linked with.  It would also get us optimized versions of the
  > 	functions in there even when cc is used for stage1.
  > 
  > We already have an N32 libiberty in $target/libiberty.  This is needed
  > because libstdc++/libio use libiberty, and they will be N32 code.  This
  > does not get built until after gcc has bootstrapped currently.  It might
  > be possible to build it after the stage1 gcc build, and then link the
  > stage2/stage3 compilers with it.  This would require rewriting the
  > bootstrap rule in the toplevel Makefile.
Jim's actually got a good point.  Doing this would require a fair amount of
surgery on the build process, but if other options don't pan out, I guess
it's what we'll have to do.

Still I think it is best if we can force the stage1 compiler to be link
compatible with the stage2/stage3 compilers.

jeff