On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero <jprot...@altera.com> wrote: > > 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.
You should have used -fno-delete-null-pointer-checks which has been doing this optimization for a long time now, just it got better with -fisolate-erroneous-paths-dereference pass. Thanks, Andrew Pinski > > 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?
