<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
I am trying to wrap my head around this discussion and its <br>
impact on RTEMS. Should we compile parts of RTEMS with<br>
this option? All of it?<br>
<br>
--joel<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: Obscure crashes due to gcc 4.9 -O2 =>
-fisolate-erroneous-paths-dereference</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Wed, 18 Feb 2015 13:30:24 -0600</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>Andrew Pinski <a class="moz-txt-link-rfc2396E" href="mailto:pinskia@gmail.com"><pinskia@gmail.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>Jeff Prothero <a class="moz-txt-link-rfc2396E" href="mailto:jprother@altera.com"><jprother@altera.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
<td>GCC Mailing List <a class="moz-txt-link-rfc2396E" href="mailto:gcc@gcc.gnu.org"><gcc@gcc.gnu.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero <a class="moz-txt-link-rfc2396E" href="mailto:jprother@altera.com"><jprother@altera.com></a> wrote:
>
> Starting with gcc 4.9, -O2 implicitly invokes
>
> -fisolate-erroneous-paths-dereference:
>
> which
>
> <a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html">https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html</a>
>
> 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?
</pre>
<br>
</div>
<br>
</body>
</html>