[Raion]

Dodoid recently was consulting with me because he had found a piece of software that he wanted to try porting but ran into the problem that it needs more than a 2 GB address space (the functional limit for n32). It was not possible to easily port this software back to MIPSPro due to its C++ use of atomics and C++ 11 features. 

I spent most of this week trying to get functional builds from multiple sources and I just can't seem to do it. And believe me, I tried. 

Here's the targets I attempted with neko_gcc:

4.7.4
4.8.5
4.9.5

I started with 4.9.5 because that is the one that I've had the most experience with trying to port. Unfortunately I did lose access to my patches because of a mistaken deletion of a backup, so I spent the early part of it fixing up my GCC patches from notes and harvesting data online. 

It basically became untenable due to bugs that were coming and going and completely nonsensical in nature, such as gmp-impl.h requiring a guard to exclude inttypes.h in the first pass but that didn't fly on the second one because xgcc (the intermediate) was either compiling in C++ mode or c89 mode instead of c99 and triggering a #error (yes I tried to fix that.) 

Before people ask yes I'm doing GCC in tree builds rather than separate installations. This is because it usually prevents error prone issues and ensures that the dependencies like GMP or (for GCC 4.8 and prior) cloog have all the proper build flags applied. This means that I am using the contrib/download_dependencies with some modifications and different versions for consistency purposes, especially including ISL or cloog or for 4.7 ppl. 

As you diverge between GCC versions C++ implementations start to break known working libraries, so I also had issues with libstdc++v3 refusing to compile and other various problems.

Eventually I got fed up trying to deal with the somewhat buggy compiler and attempted using GCC 8.2.0 from a known mostly working build. This choked almost immediately on almost anything that I threw at it probably due to the dated code. 

I did not attempt even though it was available the current GCC 9 used by RSE. My reasons were many, but namely because I haven't had a lot of good luck attempting to use recent versions of their compilers even though a lot of my attempts to restore multi-lib support are based off of patches they have.

Dodoid was interested to know if I could do a pure 64-bit target and I did in fact attempt that. No GCC version has ever supported it unfortunately and I lack the expertise at this time to fix it. 

Here's the meat of how I did it (patches won't be provided at this time just in case I'm sending someone down a false rabbit hole):

For 4.9.5 and 4.8.5 I based my patches off of comparing the didbs Daniel Hams code patches and attempting to figure out which ones and which of the smaller patches RSE uses (e.g. not the imported Fedora patches nor patches that hard code SGUG paths) would be useful. I invested probably 7 to 8 hours into that and did get some mostly working early builds but again I couldn't get very far with a multilib build, and do to limited time and resources I did not attempt non-multilib builds although I might have to at some point. I'm pretty burnt out on this after working on it all week so I decided to give it a rest and informed Dodoid of such. 

And yes I did have to do bootstraps I did not attempt a non bootstrap build because experience has not been very good with those and I have more experience dealing with a full bootstrap believe it or not. 

4.7.4 should compile without very much patches except for some bootstrap stuff and I attempted to do so with both -O1 (recommended by Orth's old posts) and -Os (which in my experience actually runs a little faster on some systems than -O2)

However it was not able to compile or complete the full bootstrap. Numerous linking issues cropped up and I wasn't able to get any verbose debugging information about why. 

From what I've read and what I understand it is possible to build a multi-lib GCC without support from the actual compiler but I did not attempt that because I did not want to complicate the build up until when I attempted with the GCC 8.2 build which was in fact singular. That didn't get too far.

[vishnu]

This is probably a stupid question, but couldn't you just cross-compile from a Linux box? Link:

https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

[Raion]

I am not gonna do that, simply put it's too much trouble and doesn't guarantee a very good result. If I was working with something much slower and older, maybe, but believe it or not each built only takes 4 or so hours

[jpstewart]

This is probably a stupid question, but couldn't you just cross-compile from a Linux box?

It is, shall we say, "non-trivial" to build a GCC cross-compiler for IRIX.  I've done it in the past.  I may be foolish enough to attempt it in the future.  It's a lot of work to get the full build environment set up and working.  And even more work to actually use that cross-compiler to build working software.

And, FWIW, when I did build cross-compilers for IRIX, I still disabled multilib and built them to target N32 only.

IME, building the cross-compiler would be as much work as (maybe more than) what Raion is doing.

[Raion]

I think the larger issue is that GCC code quality in the 4.x days was not exceptionally good, combine that with a never-well-supported platform and a mostly quick and dirty attempt to reinstate GCC support without modifying testsuites, improving more than the bare necessities etc complicates this immensely. I'm far from "I give up" and I've actually gotten pretty good at fixing minor to major build errors with GCC as long as the coding issue is documented SOMEWHERE.

A cross-compiler makes sense in very specific circumstances, moreorless, and it's simply not here.

[vishnu]

I guess, in my case, I only run the software I have that was compiled for IRIX/MIPS by the manufacturers, Maya, Shake, etc. On my Linux box I compile all the time, and I use features from the C++ standard that the MIPS/Pro compiler hasn't supported since 2006. I guess you could call that being dragged kicking and screaming into the New Millennium.😆

[Raion]

I plan to take another stab at this soon.

[vishnu]

I plan to take another stab at this soon.

I don't know why you guys are so secretive, exactly what piece of software are you talking about? And apparently Dodoid is too cool for school to show up here anymore.

[Raion]

Apparently it's some C++ based language model that he wanted to run on a tezro.

[vishnu]

I know I've said this a million times, but I think it bears repeating. My understanding is that the folks at MIPS have assigned some of their compiler programmers to assist the gcc programmers to help generate better MIPS code. But my guess would be that they're ignoring the 64-bit R-series processors we have in our SGIs, which is sad. But who knows, maybe there is an overlap between our processors and the set-top processor that MIPS has been focusing on for the last 20 years.