This is the mail archive of the
mailing list for the GCC project.
Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- From: Jeff Prothero <jprother at altera dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Wed, 18 Feb 2015 11:21:56 -0800
- Subject: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=softfail (sender IP is 22.214.171.124) smtp dot mailfrom=jprother at altera dot com; gcc.gnu.org; dkim=none (message not signed) header.d=none;
Starting with gcc 4.9, -O2 implicitly invokes
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
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?