ioccc | My IOCCC submissions and practice | Math library

The carefully crafted, self-including code in this IOCCC winning entry from 1988:

http://www.ioccc.org/years.html#1988_isaak

...was still too much for certain systems back then. Also, ANSI C was finally emerging as a stable alternative to the chaotic K&R ecosystem. As a result, the IOCCC judges also provided an ANSI version of this entry:

http://www.ioccc.org/1988/isaak.ansi.c

Its main attraction is its gimmick of including in the last line (!) with well-thought-out #defines, both inside the source and at compile time, to only allow certain parts of the code into the right level. This is what allows the header to be ultimately included at the latest stage possible, just before it is necessary, in the source fed to the compiler.

However, this version still fails to produce its output when compiled today, with the provided compiler settings:

Another pearl from the early IOCCC years is Larry Wall's 1986 entry:

http://www.ioccc.org/years.html#1986 (wall)

I suspect there is no C compiler today that can actually compile that source straight-out-of-the-box, due to the severe preprocessor abuse it contains:

• Latest TDM-GCC 9.2.0 set to ANSI mode fails
• Last TCC 0.9.27 fails

However, after wrenching the preprocessed code out of the obfuscated original (always with GCC's cpp -traditional), both TCC and GCC manage to compile it; nevertheless, GCC's effort goes to waste as the program chokes when trying to begin decoding its obfuscated intro text (not going to spoil that here for those who want to delve themselves!)

TCC, on the other hand, manages to summarily warn about implicit declarations of system(), read() and write() and quickly produce a working program.

I tried to step through the GCC code execution with GDB and that's how I found that the compiled GCC code chokes on the second pass of a for loop that goes through a text string in order to decode it:

[Inferior 1 (process 9460) exited with code 030000000005]

That process ID doesn't matter as it represents the debug build executable that crashes. The exit code, however, stays the same.

Clearly, TCC is better suited to such IOCCC entries that GCC. The latter still manages to successfully compile and even run some entries, but for tough cases like this one, TCC is hard to beat. Its only drawback is that it falls short when preprocessing extremely abusive code such as this example. It leaves spaces between certain preprocessed entries and thus fails in concatenating them into the author's intended C keywords in places, whereas GCC's cpp works 100%.

My question is, as philosophical or even rhetorical as it sounds:

What is it in modern GCC that makes it either fail to compile, or produce unusable code when it does compile, earlier C programs, unlike TCC?

Thanks in advance for all the feedback, I appreciate it!

NOTE: I am using Windows 10 version 2004 with WSL 2; GCC fails in both the Windows and the WSL 2 environments. I am planning to compile TCC in WSL 2 for comparisons in that environment too.

PS: I immensely enjoyed this program when it finally executed as intended. It undoubtedly deserves that year's "grand prize in most well-rounded in confusion"!