Hi. Folks interested in this (open to the patches described)? (sorry if it is
edited a bit out of order; and it is long)
I'm bootstrapping gcc 4.32/binutils 2.18 on Irix 6.5.
Nothing really against current gcc. I'll move to it later.
2.19.5 snapshot has obvious errors that make it fail to build out of the
box anywhere, so I gave up quickly -- in particular, the makefile doesn't
list sha1.c or something like that. I fixed that, but it calls into
question...
I'm not downloading prebuilt gcc binaries.
Perhaps I'm just making things uselessly difficult..
I'm not at this point paying for the "real" SGI compiler.
I'm not at this point faxing in something to get the "real" SGI compiler for
free (beer).
I /might/ give up and do this, but it's look unlikely to be necessary.
I tried cross building (from gcc, both Cygwin and GNU/Linux/x86), but so far
GNU ld either
- fails to find the libc, etc., even though I have a correct sys-root
- if I point it at libc directly, it hits assertion failures
I haven't dug into this. I realize binutils != gcc, but...
(I really consider these projects VERY related to each other, and gcc
is the larger more actively maintained part of it..)
So I'm back to a native bootstrap, in order to use native ld.
I found the system -- installed from scratch by me (reformated drive) --
does have a working C compiler. And perhaps C++.
In particular:
/usr/WorkShop/usr/bin/ncc very much works, for C.
I've gotten at least through stage 1 of building gcc/binutils (details to
follow)
It generally compiles stuff correctly and the results can be linked and run,
using the native linker (again -- GNU ld has problems here; though
GNU as is mandatory)
/usr/WorkShop/usr/bin/NCC checks C++ and will output C, but
doesn't go ahead and make .o files. This is probably easily
wrapped but I haven't yet.
These are clearly old versions of the EDG front end ("edgcpfe" or such).
And I think some shared SGI backend (ugen).
I believe I'm getting "O32" binaries, which I know is odd, but should be ok.
(Irix has three ABIs -- "o32" -- old 32 bit, "n32" == new 32 bit, and 64 bit.)
I built and am using GNU tar and GNU make with no patches, with this compiler.
Having run into problems on Solaris with long path symlinks (in libstdc++),
I'm leary of non-GNU tars.
Having run into errors right away with Irix make building gcc, I didn't
fight it.
Though Irix make built make, tar, and Python ok, with output in the source
directory (I know, I know,
given the inability to cross ld, I had to start somewhere..)
I built and am using Python with one patch, described below, with this
compiler.
So it is arguably a "reasonable" compiler.
I'm willing to concede under mild pressure that it is a worthless
uninteresting compiler in present context (bootstrapping gcc).
The point of this mail to determine that! :)
The entire platform may in fact no longer be interesting in present company. ?
Once I get gcc working I will proceed to port some other stuff, strictly for
fun.
No business case.
However this ncc has a /small/ number of /small/ pecularities, which so
far I can easily patch around.
- It doesn't allow // comments. binutils/t-mips.c has some.
Easy, just remove them, or change to /* */.
In this case specifically, the compiler is being reasonable.
The rest, not so, or uncertain.
- Sometimes it is confused (or maybe correct?) about the types involved in
return (a ? b : c);
one or two small patches to do:
if (a)
return b;
return c;
fixes that. In this case I didn't determine if the compiler is right.
- It is confused by C files that #include themselves, such as something like:
/* self.c */
#ifndef PRINTF
#define PRINTF printf
#define CHAR char
#include "self.c"
#undef PRINTF
#undef CHAR
#define PRINTF wprintf
#define CHAR wchar_t
#include "self.c"
#else
int PRINTF(const CHAR*, ...) { ... }
#endif
Between binutils (2.18) and gcc (4.3.2), there is one occurence of this
pattern.
Python also does this once also btw (that's the one patch it needed).
It is easily patched by moving the first chunk into selfx.c and compiling that
instead.
Granted, the dependencies of an incremental build get messed up.
In this case I'm pretty certain the compiler is wrong. I've seen this
technique before.
It "reads" correctly to a human.
- many occurences of a = obstack_alloc (...) or a = obstack (...)
I had to replace with:
a = (void*) obstack_alloc or obstack .
The code is consistent enough that it is easy to search for " = obstack" and "
= obstack_alloc"
and replace with " = (void*) obstack", nice. You know, I didn't have to
handle different whitespace
around the "=".
I didn't dig into this. The compiler thinks obstack[_alloc] returns char* and
I didn't
check if that is always the case or is configured between char* and void*.
If configury, probably fix that. If always char*, the compiler seems right
here, and I suspect
this is fixedin 4.4 anyway, for C++ compat.
- Functions in gcc's combine.c seem to give the compiler a headache. It gives
what I deemed
nonsense errors, like "lang_hook not a member of lang_hook". Since the
functions appear to
"only" be doing optimization, I neutered them by just having them return 0
or their input,
whatever appeared correct for merely doing no optimization.
It may also be reasonable to break up some of the large functions into
smaller functions, but
that is a bit lame I realize.
This last one is the one for which I most don't know how to form an acceptable
general patch.
It would probably be to come up with some #ifdefs that partition this compiler
only and
no others. Or maybe something completely manual like
BOOT_CFLAGS=-DGCC_NO_COMBINE.
So long story, sorry, -- are folks interested in
- bootstrapping from this compiler?
- more important, open to the patches, vaguely described, to make it so?
other than the combine.c one yet to be well formulated, I think they are
pretty ok patches,
that don't screw up the code for everyone in the interest of the out-lier
I realize, the actual patches would need to be presented -- though I've made
them mostly obvious.
But I'm just wondering if I should go the effort of presenting them .. porting
to current, etc.
I don't have them in an acceptable form yet. I apply them manually the first
few times, then when
I got tired of that, I apply them programmatically with Python. I'm loath to
maintain a bunch
of actual fragile diffs, with line numbers and such, and so far, not needed.
So far code to apply them
has felt less fragile, like "remove such and such a line", or "add line after
line", or "search and replace" --
no line numbers, and they are all contained in one file. Maybe diff works
well with context, and line
numbers aren't important, I don't know.
If nothing else -- collectors of non-gcc compiler bug lore -- I give you the
above. :)
- Jay
