Why undefined behavior may call a never-called function
I suspect this is another critical point:<p><i>as NeverCalled may have been called from, for example, a global constructor in another file before main is run</i><p>clang doesn&#x27;t analyse across module boundaries --- even when it theoretically could --- so it doesn&#x27;t know for certain that NeverCalled() is indeed never called.<p>Throughout the years I&#x27;ve grown increasingly displeased at how compilers handle even trivial cases like this[1][2][3], and in particular their treatment of UB[4][5][6][7]; as one of the comments on the article implies, UB was unlikely intended by the standard&#x27;s authors as a &quot;you <i>should</i> let the most inane things happen&quot; but more as a &quot;do what makes the most sense&quot;.<p>A more sensical approach to analysing this program, e.g. as employed by a human, would be to see that NeverCalled() is the only function that can write Do, <i>but then further ascertain whether it is actually called</i>. Since this is the entire program, it&#x27;s trivial to see that it&#x27;s not, and thus that possibility should also have been removed from the set of possible values for Do. Thus, Do can neither be EraseAll nor 0 --- so a &quot;contradiction&quot; has occurred, the code is likely bugged or the programmer intentionally wants the UB, and the sane choice at this point would be to forget about trying to optimise and just generate the obvious code. &quot;I can&#x27;t figure out how to optimise this, so I&#x27;ll do the simplest thing that works.&quot;<p>The question then becomes, why can a human see something so straightforward but the compiler can&#x27;t? I think that&#x27;s the deeper issue here with how the compilers like gcc&#x2F;clang today work --- they&#x27;re too opaque and complex, and their authors take The Holy Standard as gospel while ignoring the practical realities of their decisions.<p>Unfortunately a lot of programmers have gotten the notion that they can rely on the compiler to do &quot;amazing&quot; optimisation, and therefore they can write horrible code, leading to horribly unintuitive and &quot;overly aggressive&quot; optimisation like this.<p>I&#x27;m sure that me, along with quite a few others, have some ideas for how to make a C&#x2F;C++ compiler which is both powerful in optimisation and code generation, but more predictable and &quot;obvious&quot; in terms of UB. Unfortunately, I&#x27;m also sure that we don&#x27;t have the time to do it.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15006090" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15006090</a><p>[2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9397924" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9397924</a><p>[3] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15188416" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15188416</a><p>[4] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11147598" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11147598</a><p>[5] <a href="http:&#x2F;&#x2F;blog.metaobject.com&#x2F;2014&#x2F;04&#x2F;cc-osmartass.html" rel="nofollow">http:&#x2F;&#x2F;blog.metaobject.com&#x2F;2014&#x2F;04&#x2F;cc-osmartass.html</a><p>[6] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7960219" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7960219</a><p>[7] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9809885" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9809885</a>