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

[Mehdi Amini via llvm-dev]

> On Mar 16, 2016, at 10:08 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
> 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.

I'll add that there is a great reading on the llvm blog on this topic: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Best,

-- 
Mehdi