[cfe-dev] Reporting UBSan issues at compile-time

[David Blaikie via cfe-dev]

On Thu, Mar 23, 2017 at 10:45 AM Reid Kleckner <rnk at google.com> wrote:

> On Thu, Mar 23, 2017 at 8:18 AM, David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> 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).
>
>
> 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.
>
> 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).
>
>
> I don't think it will be feasible to generalize UBSan's knowledge to the
> static analyzer.
>

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.


> The static analyzer CFG is also at best an approximation of the real CFG,
> especially for C++.
>

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.


>
>
> On Wed, Mar 22, 2017 at 6:52 PM Vedant Kumar via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> === Approach ===
>
> I wrote a simple analysis which detects UB statically by piggybacking off
> UBSan.
> It's actually able to issue decent diagnostics. It only issues a
> diagnostic if
> it finds a call to a UBSan diagnostic handler which post-dominates the
> function
> entry block.
>
> The idea is: if a function unconditionally exhibits UB when called, it's
> worth
> reporting the UB at compile-time.
>
>
> 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.
>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170323/b6265ea5/attachment.html>