From: Andrew Pinski <pinskia@gmail.com>
To: Jeff Prothero <jprother@altera.com>
Cc: GCC Mailing List <gcc@gcc.gnu.org>
Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
Date: Wed, 18 Feb 2015 19:30:00 -0000 [thread overview]
Message-ID: <CA+=Sn1mvKSyvY99xRcWJtcOxRoHzDSR8X5p59xXYE98q9OCP7Q@mail.gmail.com> (raw)
In-Reply-To: <pdf61azt48b.fsf@sj-interactive3.altera.com>
On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero <jprother@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?
next prev parent reply other threads:[~2015-02-18 19:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 19:24 Jeff Prothero
2015-02-18 19:29 ` Jakub Jelinek
2015-02-19 20:56 ` Sandra Loosemore
2015-02-19 21:16 ` Daniel Gutson
2015-02-19 22:10 ` Jakub Jelinek
2015-02-19 22:26 ` Sandra Loosemore
2015-02-19 21:23 ` Joel Sherrill
2015-02-19 21:56 ` Chris Johns
2015-02-20 17:30 ` Jeff Law
2015-02-26 16:23 ` David Malcolm
2015-02-27 20:55 ` [RFC/patch for stage1] Embed compiler dumps into generated .o files (was Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference) David Malcolm
2015-02-20 11:06 ` Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference Florian Weimer
2015-02-20 11:43 ` Jonathan Wakely
2015-02-20 12:05 ` Florian Weimer
2015-02-20 17:01 ` Jeff Law
2015-02-20 17:09 ` Florian Weimer
2015-02-20 17:32 ` Jeff Law
2015-02-20 18:01 ` Paul_Koning
2015-02-20 12:11 ` Jakub Jelinek
2015-02-20 17:03 ` Jeff Law
2015-03-03 19:57 ` Martin Sebor
2015-03-03 23:38 ` Jeff Law
2015-03-04 12:36 ` Richard Biener
2015-02-20 12:13 ` Andrew Haley
2015-02-20 17:03 ` Jeff Law
2015-02-18 19:30 ` Andrew Pinski [this message]
2015-02-20 9:30 ` Andrew Haley
2015-02-20 11:45 ` Florian Weimer
2015-02-20 17:01 ` Jeff Law
2015-02-20 18:07 ` Paul_Koning
2015-02-20 1:04 Jeff Prothero
2015-02-27 22:13 Manuel López-Ibáñez
2015-03-03 8:41 ` Chris Johns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+=Sn1mvKSyvY99xRcWJtcOxRoHzDSR8X5p59xXYE98q9OCP7Q@mail.gmail.com' \
--to=pinskia@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jprother@altera.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).