[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.