[llvm-dev] Clang -O0 performs optimizations that undermine dynamic bug-finding tools

[Manuel Rigger via llvm-dev]

2017-03-21 17:47 GMT+01:00 Daniel Berlin <dberlin at dberlin.org>:

>  can still detect them.
>>
>> Following, I have the following questions/suggestions:
>> - Is it known that Clang performs optimizations that hide program bugs,
>> even when compiling with -O0?
>>
> Some, yes, some no.
>

I was too unspecific about this question. I can imagine that constant
folding at -O0 could hide signed integer overflow bugs and undefined
behavior in arithmetic expressions. However, I'm mainly interested in
memory errors (buffer overflows, NULL dereferences, double-free and invalid
free errors, reads of uninitialized data and others). Are there any records
where memory errors were optimized away at -O0, besides the ones that I
found?

>
>
>> - Are there command line options to specify that no optimizations should
>> be performed?
>>
>
> It is not possible to compile all code correctly without optimization,
> interestingly enough.  It would be nice though.
> In fact, i expect things like C++ constexpr make this significantly worse.
>
> I think that there is a difference in language semantics and how the
compiler implements it. For example, even though constexpr requires that a
value can be evaluated at compile-time, a compiler is not required to
actually do it. I think that if optimizations in the compiler are required
to correctly implement a language construct then it is an implementation
detail of the compiler, or not an optimization. I'm not sure if you were
talking about this implementation level or in general. In general, I'm not
(yet) convinced that any code requires compiler optimizations to be
implemented correctly.


>
>> Until recently, I thought that -O0 had this effect.
>> - In each case, I would propose to not perform optimizations at -O0 to
>> allow dynamic bug finding tools to find such bugs, or at least offer a flag
>> to turn off optimizations altogether.
>>
>> Again, this is impossible :)
> For example, there are high profile things that depend on always_inline
> functions not existing after inlining.
>

IMO, always_inline functions that are inlined fall into the category of
language semantics. Anyway, I get your point that the line cannot always be
clearly drawn.

This inlining can definitely hide bugs (smashing call stacks, etc).
> But we have to do it anyway.
>

Inline functions can hide bugs if the bug finding tool is based on a canary
approach. However, if the bug finding tool provides detection of
out-of-bounds accesses (which all tools that I consider to be bug finding
tools do) then out-of-bounds writes to the stack, such as overwriting the
return address, are detectable either way.

>
> So as a general statement, your proposal will not work.
> If you revised it to "the minimum set of optimizations necessary for
> correctness", it would be doable, but that set already conflicts in a
> number of ways with "dynamic bug finding tools" :(
>
> It certainly also depends on whether there is a consensus (is there one?)
on how Clang should behave when compiling with -O0. I see two different
ways here:

   - Clang should optimize code if it does not increase compilation time
   but has a clear run-time performance advantage.
   - Clang should refrain from performing any (or as many as possible)
   optimizations for debugging purposes and bug finding tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/e8be8089/attachment.html>