[llvm-dev] How to let LLVM handle undefined behavior more gracefully?

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 16 22:08:24 PDT 2016


On 16 March 2016 at 21:42, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Yes, thought of UBSan. But in our case, the target program runs on
> baremetal. It has very tight code size restriction and it has no stderr.
> Since LLVM already caught the behavior during compilation, it should notify
> users about it.

It's not that simple.

First, without debug info all LLVM could realistically say is "there
might be undefined behaviour somewhere in this program". Even with
debug info, that location may or may not be accurate.

Second, there could be legitimate cases for an shl 32 to exist in a
program. As long as it's not actually executed it's fine. The usual
example is a template instantiation: they fairly often have generic
code that would be UB in some cases, but is guarded by checks to never
execute at runtime. There's no realistic way for LLVM to determine
this locally.

Third, we don't want the diagnostics Clang produces to depend on
optimization level.

If you want this kind of diagnostic at compile-time, it's probably a
job for the static analyzer. It doesn't currently catch this case
though, and I don't know enough about its inner workings to say how
feasible that would be.

Cheers.

Tim.


More information about the llvm-dev mailing list