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

[Reid Kleckner via cfe-dev]

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. The static analyzer CFG is also at best an approximation
of the real CFG, especially for C++.


> 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/6afdf722/attachment.html>