Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths-dereference:
which
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
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
unexpected.
Is there any good reason the
-fisolate-erroneous-paths-dereference
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. :-)
-Jeff
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?
