SGI: Development

Has anyone looked into getting a modern version of GCC to run on IRIX 4? I have an Indigo running 4.0.5F and have toyed with builds on and off for a while, with little promise of success until recently.

The most recent version of GCC that will build successfully on IRIX 4 without modifications is GCC 3.0.4. 3.1 and 3.2 have problems with gcc/config/mips/mips.md, and after that the GCC folks dropped compatibility with older versions of IRIX. However I recently succeeded, with some source modifications, in building cross-compilers of 3.4.6 and 4.1.2 (x64 NetBSD host). Unfortunately I can't get 3.4.6 to build natively. The first major problem is a command line that exceeds NCARGS (only 10248!) but even after circumventing that problem I get internal GCC errors before the end of the build. I have not yet invested the time to try building 4.1.2 natively but will soon. And I thought gcc builds on my Octane2 were slow!

If anyone else is working on this or has any advice, I'd love to hear it. I bet this work could be leveraged to IRIX 3 too, they are very similar from GCC's perspective.

I've been building GCC on IRIX 3 a couple of years ago and the biggest problem is the pre-ANSI C library.

I put together a compatibility library to cover some of that and with that I could build GCC 3.0.4 on IRIX 3.3.

I suppose you mean a R4k Indigo, or are you actually building 3.x gccs on an R3k?

hbent wrote: And I thought gcc builds on my Octane2 were slow!

I'm currently bootstrapping some 3.x gccs on a SPARCclassic

But nice project. I once build 3.4.6 for 5.3 (didn't go further because I was too lazy building gcc's dependencies), but didn't go down to 4 with gcc on my Indigo², yet.

I did mean an R4k Indigo, doing this on an R3k would be like watching paint dry. Though I did build 3.3.6 once on a Mac IIci running A/UX, as I recall it took well over 24 hours, probably very similar to working on a SPARCclassic.

My main motivation is to get to a version of GCC that knows about the R4000 errata. I'm hoping it will fix the coredumps I sometimes get when compiling software with -mips2.

Somewhere in the early GCC 3.x series it stopped working on R3K CPUs. I suspect someone used R4K instructions in the crtbegin/crtend assembly code.

hbent wrote: I did mean an R4k Indigo, doing this on an R3k would be like watching paint dry.

That, or you need something with *a lot* of R3000 CPU's, like a PowerSeries 'Predator' rack

jan-jaap wrote: Somewhere in the early GCC 3.x series it stopped working on R3K CPUs. I suspect someone used R4K instructions in the crtbegin/crtend assembly code.

Aren't the various crt* files provided by the operating system? gcc does not provide such files.

miod wrote: Aren't the various crt* files provided by the operating system? gcc does not provide such files.

GCC on IRIX provides crtbegin.o and crtend.o to deal with constructor/destructor stuff.

Edit: crtbegin/end are built from C code, but the mips specific code does contain two asm files. Or maybe the GCC code generator got borked, who knows.

jan-jaap wrote:

miod wrote: Aren't the various crt* files provided by the operating system? gcc does not provide such files.

GCC on IRIX provides crtbegin.o and crtend.o to deal with constructor/destructor stuff.

Ah, right, the joys of the collect2-as-an-ld-wrapper platforms.

jan-jaap wrote: Edit: crtbegin/end are built from C code, but the mips specific code does contain two asm files. Or maybe the GCC code generator got borked, who knows.

Well, the two .S files seem mips1-compatible to me. What may be wrong, OTOH, are the stack adjustments. The mips default frame size in gcc-produced code has changed several times over gcc development, and since almost noone tests gcc on IRIX < 5 those days, it is very likely that a stack frame size change has been applied everywhere but in gcc/config/mips/crt[in].asm...

miod wrote: Well, the two .S files seem mips1-compatible to me. What may be wrong, OTOH, are the stack adjustments. The mips default frame size in gcc-produced code has changed several times over gcc development, and since almost noone tests gcc on IRIX < 5 those days, it is very likely that a stack frame size change has been applied everywhere but in gcc/config/mips/crt[in].asm...

Frames are definitely my problem at the moment. The cross-compiler generates them correctly:


but the native compiler is totally wacked:



I was working on the assumption that it was a problem with the compiler I was using to build gcc, and have switched to a different one for the run I'm doing now. Is there something else I should look into?

hbent wrote: Frames are definitely my problem at the moment. The cross-compiler generates them correctly:

Code: Select all

.frame  $fp,24,$31              # vars= 0, regs= 2/0, args= 16, gp= 0


but the native compiler is totally wacked:

Code: Select all

.frame  $fp,12698368,(null)             # vars= 24, regs= 269896524/0, args= 0, gp= 0


I was working on the assumption that it was a problem with the compiler I was using to build gcc, and have switched to a different one for the run I'm doing now. Is there something else I should look into?

This smells like variadic functions (in that case, fprintf), are not working correctly. Are you sure your native compiler is built as an o32 binary (I'm not 100% sure anymore, but I doubt I am wrong assuming IRIX 4 uses the o32 ABI). Furthermore, if you're on an R4000 system, are you sure the native compiler isn't trying to output 64 bit code behind your back, or isn't built to expect an n64 world? An n32 vs o32 problem seems more likely so far, though.

miod wrote: I'm not 100% sure anymore, but I doubt I am wrong assuming IRIX 4 uses the o32 ABI).

i'm afraid you are. irix4 is coff.

or isn't built to expect an n64 world?

n64 was introduced with irix 6.0.

An n32 vs o32 problem seems more likely so far, though.

not so much, see above.