Good luck on the upgrade Conner! Hardware sucks.
Warning: BOOK ahead. I guess I'm in narration mode today, sorry!
The argument of not believing a problem exists because it hasn't happened to you, personally, reminds me of an old comic argument involving cartographers.
"Why do we need to redraw all these maps? They're fine!"
"Well, no, they're all wrong. Those maps were drawn by people who believed the world was flat. We now know it's round, and so the scale of everything is off."
"Are you SURE? I've been sailing from these maps for years and always found my way around."
"Yes! You can't accurately draw a map of a sphere on a flat rectangle unless you use one of these methods that warps the lines to simulate the curve."
"I dunno. Have you checked to make sure the world is REALLY round? I trust these maps a lot more than I trust your theories!"
The fact is, compilers don't really have all THAT many bugs, per se. It's a pretty rare event for someone to find a compiler bug that produces incorrect (assembly) code, and those get jumped on pretty quick. The vast majority of patches done to compilers are to tighten up error handling and detection. gcc 4.x checks for a great many things, in terms of code usage, that gcc 3.x didn't even try to check.
It's entirely possible to have code that works perfectly for years, suddenly break with a new compiler. Sometimes that's because it now detects things you did wrong, but got away with. Sometimes, the compiler itself now handles things differently and the way you did things before doesn't work. How can you tell the difference? You can try gcc -S. That produces assembly code. If you have the old and new compilers both installed, you can have them each compile the same file and then look at the resulting assembly code.
Does it matter? Well, not really. In computers, we have two options. You can stop upgrading at a "tried and true" version, and live with the fact that you will gradually be left behind and that fewer and fewer people will be able to use what you produce, or you can keep upgrading and going back to revise your code.
I've nursed WileyMUD from it's original home on a Sun 3/60 running SunOS 3.x (Motorola 68040 CPU, SunOS was mostly BSD-derived), to a Sun 4/110 running SunOS 4.x (SPARC CPU), to a Sparc 10 running Solaris (Solaris is mostly SYSV-derived), and then to an i486 Linux 1.1.x box (Slackware), a Pentium 90 box (Redhat), a P333 box (OpenBSD!), and finally the P3-933 (Debian) box it's sitting on now.
In that 15 year journey, we've gone from the stock /bin/cc that SunOS provides, to gcc 2.x, to the stock cc from Solaris, to gcc 3.x in several environments, and to gcc-4.1.2 now. EVERY time I've had to go through and re-fix things, and almost every time I've found things that someone (maybe me, maybe the Diku authors, maybe one of the other devs from years ago) did that was clearly wrong, but that the older compiler let slide.
I think people who are already here, and already use Smaug, will be able to adapt to changes as they come along. I don't want to abandon folks on older systems either, but I also don't want to see things stall out because too much energy is being devoted to keeping things running on the older systems.
It might be as simple as putting some comments in the Makefile on ways to get things running with older compilers. "If you're using gcc 3.x, disable these warnings. If you're in FreeBSD, do this. In ALL cases, be aware that things might be broken if you do this."