Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

Jeff Prothero jprother@altera.com
Wed Feb 18 19:24:00 GMT 2015

Starting with gcc 4.9, -O2 implicitly invokes




documents as

    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 results in a sizable number of previously working embedded programs mysteriously
crashing when recompiled under gcc 4.9.  The problem is that embedded
programs will often have ram starting at address zero (think hardware-defined
interrupt vectors, say) which gets initialized by code which the
-fisolate-erroneous-paths-deference logic can recognize as reading and/or
writing address zero.

What happens then is that the previously running program compiles without
any warnings, but then typically locks up mysteriously (often disabling the
remote debug link) due to the trap not being gracefully handled by the
embedded runtime.

Granted, such code is out-of-spec wrt to C standards.

None the less, the problem is quite painful to track down and

Is there any good reason the 


logic could not issue a compiletime warning or error, instead of just
silently generating code virtually certain to crash at runtime?

Such a warning/error would save a lot of engineers significant amounts
of time, energy and frustration tracking down this problem.

I would like to think that the spirit of gcc is about helping engineers
efficiently correct nonstandard pain, rather than inflicting maximal
pain upon engineers violating C standards.  :-)


BTW, I'd also be curious to know what is regarded as engineering best
practice for writing a value to address zero when this is architecturally
required by the hardware platform at hand.  Obviously one can do various
things to obscure the process sufficiently that the current gcc implementation
won't detect it and complain, but as gcc gets smarter about optimization
those are at risk of failing in a future release.  It would be nice to have
a guaranteed-to-work future-proof idiom for doing this. Do we have one, short
of retreating to assembly code?

More information about the Gcc mailing list