Why do I see crashes when I use Null pointer dereferencing in the nios2-elf-gcc 4.9 ToolChain?

Description

In the Quartus® II software version 15.0, Nios® II code compiles using the nios2-elf-gcc 4.9 toolchain. When compiling code at -O2 (or higher) with nios2-elf-gcc 4.9 toolchain, the optimization -fisolate-erroneous-paths-dereference will be switched ON by default.

As described in

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options,

-fisolate-erroneous-paths-dereference

Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer. Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap. This flag is enabled by default at -O2 and higher.

This optimization means when the toolchain detects the code is trying to load or store through a possible null pointer, it will change the load or store statement into a trap instruction. This may cause embedded program to crash without a compile-time warning.

Resolution

If your design contains valid data at address zero, compile your code using the following switch to avoid issues related to null pointer dereferences:

-fno-delete-null-pointer-checks