<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-03-21 17:47 GMT+01:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> can still detect them.</div><div><br></div><div>Following, I have the following questions/suggestions:</div><div>- Is it known that Clang performs optimizations that hide program bugs, even when compiling with -O0?</div></div></blockquote></span><div>Some, yes, some no.</div></div></div></div></blockquote><div> </div><div>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?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>- Are there command line options to specify that no optimizations should be performed? </div></div></blockquote><div><br></div></span><div>It is not possible to compile all code correctly without optimization, interestingly enough.  It would be nice though.</div><div>In fact, i expect things like C++ constexpr make this significantly worse.</div><span><div><br></div></span></div></div></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Until recently, I thought that -O0 had this effect.</div><div>- 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.</div><div><br></div></div></blockquote></span><div>Again, this is impossible :)</div><div>For example, there are high profile things that depend on always_inline functions not existing after inlining.</div></div></div></div></blockquote><div><br></div><div>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.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This inlining can definitely hide bugs (smashing call stacks, etc).</div><div>But we have to do it anyway.</div></div></div></div></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>So as a general statement, your proposal will not work.</div><div>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" :(</div><div><br></div></div></div></div>
</blockquote></div>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:</div><div class="gmail_extra"><ul><li>Clang should optimize code if it does not increase compilation time but has a clear run-time performance advantage.</li><li>Clang should refrain from performing any (or as many as possible) optimizations for debugging purposes and bug finding tools.</li></ul></div></div>