<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 23, 2017 at 8:18 AM, David Blaikie via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FWIW - Clang is fairly allergic to emitting diagnostics based on optimization because they tend to present usability problems. They can appear/disappear due to seemingly unrelated changes in the code (that trigger or hinder optimizations that cause the diagnostic path to be hit).<br></div></blockquote><div><br></div><div>I was going to say this, but users keep asking for UB warnings from the middle-end. At some point, we might want to throw them a bone and give them something. =) We wouldn't want to enable such warnings by default, though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Usually the idea is to implement these sort of bug finding techniques in Clang's static analyzer. So perhaps there would be a way to feed UBSan's facts/checks into the static analyzer in a more consistent way (I'm sure some of the same checks are implemented there already - but generalizing/unifying UBSan's checks to feed into the static analyzer could be handy).<br></div></blockquote><div><br></div><div>I don't think it will be feasible to generalize UBSan's knowledge to the static analyzer. The static analyzer CFG is also at best an approximation of the real CFG, especially for C++.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_quote"><div dir="ltr">On Wed, Mar 22, 2017 at 6:52 PM Vedant Kumar via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=== Approach ===<br class="m_-1625626292530101780gmail_msg">
<br class="m_-1625626292530101780gmail_msg">
I wrote a simple analysis which detects UB statically by piggybacking off UBSan.<br class="m_-1625626292530101780gmail_msg">
It's actually able to issue decent diagnostics. It only issues a diagnostic if<br class="m_-1625626292530101780gmail_msg">
it finds a call to a UBSan diagnostic handler which post-dominates the function<br class="m_-1625626292530101780gmail_msg">
entry block.<br class="m_-1625626292530101780gmail_msg">
<br class="m_-1625626292530101780gmail_msg">
The idea is: if a function unconditionally exhibits UB when called, it's worth<br class="m_-1625626292530101780gmail_msg">
reporting the UB at compile-time.<br class="m_-1625626292530101780gmail_msg"></blockquote></div></div></div></div></blockquote><div><br></div><div>Checking for ubsan handlers that post-dominate a function entry block seems like a weak heuristic. If you put that code inside an if, or if main is inlined into a block that doesn't post-dominate the entry of the caller, we won't warn on it.</div><div><br></div><div>What if we had a way of tagging certain branches as "warn if this branch is optimized to true", and then we had hooks from branch simplification utilities to emit warnings? That seems like it might find a lot more bugs, but it could have false positives in dead code. Do you think that could work?</div></div></div></div>