are folks interested in native bootstrapping on SGI with a slightly odd native compiler?

Sun Sep 28 06:00:00 GMT 2008

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"


 int PRINTF(const CHAR*, ...) { ... }


 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

More information about the Gcc mailing list