 <p>I don't know if I would call it crashing, but sdcc (<a href="http://en.wikipedia.org/wiki/Small_Device_C_Compiler" rel="nofollow noreferrer">Small Device C Compiler</a>) fails at compiling code formed in a particular way:</p> <ul> <li>Target: <a href="http://en.wikipedia.org/wiki/Intel_8051" rel="nofollow noreferrer">8051</a></li> <li>Code had to execute in a 512 byte cache loaded from an external tester</li> <li>Tester is in control and stores the code - cache can't fetch the next page</li> <li>No function calls allowed - the PC (program counter) would skip to a place not resident in cache; preprocessor macros were used to accomplish modular coding practice </li> <li>Jumps (branching) allowed if it doesn't skip out of the cache</li> <li>No const values - in the data section of the program code which causes code in cache to fetch something not in cache - preprocessor constant (#define) OK here</li> </ul> <p>The preprocessor macros are unrolled resulting in flat, but large code - everything in main(); execution skips the startup code (setting up the stack, etc) and starts at the beginning of main()</p> <p><strong>Relevant part of this answer:</strong></p> <p>Occasionally, sdcc would refuse to compile syntactically correct code, with a message about running out of memory. This even happened compiling on 64-bit boxes with 8GB of RAM.</p> <p>The solution in these cases was to split the firmware into separate pieces and compile them separately and execute them separately. The pieces may have been able to be linked back together, but at that point it didn't matter.</p> <p>I didn't try it, but the <a href="http://www.keil.com/" rel="nofollow noreferrer">Keil</a> 8051 compiler probably could have handled the problematic code.</p>