This is the mail archive of the
mailing list for the GCC project.
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Prothero <jprother at altera dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 18 Feb 2015 20:29:43 +0100
- Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- Authentication-results: sourceware.org; auth=none
- References: <pdf61azt48b dot fsf at sj-interactive3 dot altera dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
> 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.
If you have some pages mapped at address 0, you really should compile your
code with -fno-delete-null-pointer-checks, otherwise you can run into tons
of other issues.
Also, there is -fsanitize=undefined that allows discovery of such invalid
calls at runtime, though admittedly it isn't supported for all targets.