<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 3:34 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Seems like there ought to be some kind of "unreachable" warning on the "return 0;" statement?</span></p></div></div></blockquote><div><br></div><div>Possible - though it's nice not to diagnose something twice in different ways (to reduce noise, etc). But, yeah - it looks like Clang's CFG analysis infrastructure hasn't been taught that these idioms are constant conditions, thus making unreachable code. (also our -Wunreachable-code warning is still off by default, despite several improvements to the warning to make it a bit less bad - I haven't re-evaluated it in a while to see whether it has any major holes left)<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="148900d714507b5b__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>David Blaikie<br>
<b>Sent:</b> Friday, September 19, 2014 7:25 AM<br>
<b>To:</b> Martin Richtarsky; Nick Lewycky<br>
<b>Cc:</b> cfe-dev Developers<br>
<b>Subject:</b> Re: [cfe-dev] Addresses of referenced objects in clang 3.5<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p>(+Nick who had a hand in implementing this optimization)<u></u><u></u></p>
<p>I don't think there's a flag to control this, no.<u></u><u></u></p>
<div>
<p class="MsoNormal">On Sep 19, 2014 1:47 AM, "Richtarsky, Martin" <<a href="mailto:martin.richtarsky@sap.com" target="_blank">martin.richtarsky@sap.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi,<br>
<br>
since clang 3.5 code as below is optimized away with -O1, assuming that the address of the object<br>
can never be NULL:<br>
<br>
class A { };<br>
<br>
int func(A& a)<br>
{<br>
if (&a)<br>
{<br>
return 1;<br>
}<br>
return 0;<br>
}<br>
<br>
int main()<br>
{<br>
A &a = *reinterpret_cast<A *>(0);<br>
return func(a);<br>
}<br>
<br>
clang++ -Wall -O1 ptrnull.cpp -o ptrnull<br>
<br>
ptrnull.cpp:5:10: warning: reference cannot be bound to dereferenced null pointer<br>
in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion]<br>
if (&a)<br>
~~ ^<br>
1 warning generated.<br>
<br>
<br>
./ptrnull<br>
Return code: 1<br>
<br>
This is as described in the release notes.<br>
<br>
When changing func() as follows the warning is not shown, but clang still performs<br>
the same optimization. Shouldn't the warning be shown here aswell?<br>
<br>
int func(A& a)<br>
{<br>
A *aptr = &a;<br>
if (aptr)<br>
{<br>
return 1;<br>
}<br>
return 0;<br>
}<br>
<br>
Is it possible to disable this optimization specifically (without resorting to -O0)<br>
to gradually fix codebases that rely on such checks? I saw that I can use<br>
-fsanitize=null, which helps, but disabling the optimization would still<br>
be the best temporary workaround.<br>
<br>
Thanks and Best regards,<br>
Martin<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div>