<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 23, 2017 at 10:55 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Mar 23, 2017 at 10:45 AM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4816353318239515335gmail_msg"><div class="gmail_extra m_4816353318239515335gmail_msg"><div class="gmail_quote m_4816353318239515335gmail_msg"><div class="m_4816353318239515335gmail_msg">I don't think it will be feasible to generalize UBSan's knowledge to the static analyzer.</div></div></div></div></blockquote></span><div><br>Why not? The rough idea I meant would be to express the constraints UBSan is checking into the static analyzer - I realize the current layering (UBSan being in Clang's IRGen) doesn't make that trivial/obvious, but it seems to me that the constraints could be shared in some way - with some work.<br></div></div></div></blockquote><div><br></div><div>Maybe I am not imaginative enough, but I cannot envision a clean way to express the conditions that trigger UB that is useful for both static analysis and dynamic instrumentation. The best I can come up with is AST-level instrumentation: synthesizing AST nodes that can be translated to IR or used for analysis. That doesn't seem reasonable, so I think getting ubsan into the static analyzer would end up duplicating the knowledge of what conditions trigger UB.</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"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_4816353318239515335gmail_msg"><div class="gmail_extra m_4816353318239515335gmail_msg"><div class="gmail_quote m_4816353318239515335gmail_msg"><div class="m_4816353318239515335gmail_msg"> The static analyzer CFG is also at best an approximation of the real CFG, especially for C++.</div></div></div></div></blockquote></span><div><br>Sure enough - and I believe some of the people working/caring about it would like to fix that. I think Manuel & Chandler have expressed the notion that the best way to do that would be to move to a world where the CFG is used for CodeGen, so it's a single/consistent source of truth.<br></div></div></div></blockquote><div><br></div><div>Yes, we could do all that work, but LLVM's CFG today is already precise for C++. If we allow ourselves to emit diagnostics from the middle-end, we can save all that work.</div><div><br></div><div>Going down the high-effort path of extending the CFG and abstracting or duplicating UBSan's checks as static analyses on that CFG would definitely provide a better diagnostic experience, but it's worth re-examining conventional wisdom and exploring alternatives first.</div></div></div></div>