This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


	Also, for cases (xcoff/elf, n32/64) where the compiler has
	multiple output backends, the configure switch should cut out the code for
	the undesired backends.

There aren't any mips ports that support both xcoff and elf

I suspect that the irix6 port is the only mips workstation port that does
multilibbing, and it does so for compatibility with the SGI C compiler which
does essentially the same thing.  If anything, I would like to increase the
list to include [o]32 in addition to n32/64, for even better compatibility.
The o32 support isn't working though because of conflicts with the n32 support.

The extra support in the compiler itself is trivial.  The only real cost here
is the size of the libraries, which are compiled once for each multilib.

	I would
	however like to see some easy way to change the default set of -m switches
	gcc uses.  SGI's compilers for example read an envariable (SGI_ABI) and a
	file in /etc to decide which ABI to default to. 

I disagree.  I think SGI's scheme is a serious mistake.  We have enough trouble
getting people to report enough info to allow us to reproduce a problem.
Imagine how much trouble we would have if we also need them to report the
contents of a file in /etc which they have never heard of.  There is a similar
problem with envinronment variables, which people will set and then forget
about.

This will also cause trouble for people trying to port programs from one
SGI machine to another.  A program that compiles fine on one machine may
fail miserably on another, just because a file in /etc that you didn't know
was there caused the C compiler to behave differently, or because the
person compiling it had set the SGI_ABI environment variable differently.
Makes me shudder to think of it.  I hardwired `cc -32' into the irix6
configuration to try to avoid this problem.

In any case, if you really want to fiddle with the defaults, there is already
a way to do this: you can modify the specs file.  If you do this though, you
had better remember to mention this in all bug reports, otherwise you will
get confused answers because we won't be able to reproduce your problems.

	There's also a nice feature
	of Sun's compilers, the -native switch, which means "tune code and issue
	instructions for the chip I'm compiling on." This may be too hard to
	implement (how do you know which chip you're on?) though.

This does sound useful.

On an SGI, `hinv' will reliably tell you what chip you are on.  Many other
OS's also have some way to determine what chip you are on.  This could be
determined at configure time if this is a native.  If this is a cross, you
have to specify the target explicitly anyways, so we could rely on the user
to optionally specify it.

It would take some work to implement this though, as practically every port
would be affected.

Jim

PS I am started looking into the remaining c-torture failure, but got
distracted by other work so I haven't finished it yet.  irix6 has a strange
structure passing/return convention, and this support was accidentally broken
by this change:

Mon Jul 28 11:22:16 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* stor-layout.c (layout_type): Fix ancient code to match ancient
	comment.  Use mode of field for one-field structs.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]