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

[Jim Wilson <wilson at cygnus dot com>]

	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.

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.

	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.

I never tested any compiler after 7.0beta, by then I had gotten in the habit
of always using cc -32 when using the SGI compiler.  My suspicion though
is that bootstrapping with -n32 would work with 7.1 and later compilers.
The 7.1 compilers have probably been out for 2 years or so by now.

	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.

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

The config/mh-irix6 stuff was inherited from Cygnus when we adopted the
Cygnus top level configuration directory.  This stuff stopped working for
Cygnus when Ian Taylor fixed a toplevel configure bug.  That was sometime in
1997 I believe.  I don't think anyone has seriously looked at this issue, but
my feeling is that we can't make CC definitions in config/m*-* files work
anymore, because this is inconsistent with other features of configure.
And for the same reasons, setting CFLAGS there won't work either.  It is
probably a bit of work to fix this.  I think we would need to create a new
toplevel host dependent compiler option variable, which can be set in a
config/m*-* file, and then modify configure and/or Makefile to pass it along
with CFLAGS to the host CC.

My recollection of the exact problem with the toplevel configure file is
hazy, but it has something to do with the fact that CC and CFLAGS are allowed
to be specified by the user.  Hence we get them from the user if the user
specified them, otherwise we use gcc if it exists, otherwise we default to cc.
There is a complication here when reconfiguring after an update, e.g.
	./config.status --recheck
which needs to get CC from the Makefile, because there might be a user
specified value there from the original configure command.  The changes to
make this work right are what caused the config/m*-* file to stop working.

Hmm, maybe we can make configure default to DEFAULT_CC instead of cc, and
then let a config/m*-* file override DEFAULT_CC?  This probably requires fixing
the code that re-extracts CC from the Makefile though.

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.  We have X_CFLAGS, but I don't
know whether that works anymore either.  I suspect it does work, however,
this doesn't help with libiberty, it only helps with gcc.

	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

PS I have version 7.1 of the SGI C compiler on my machine.  I am trying a
cc -n32 bootstrap just to see what happens.