&gt; But if it did that, there might be target architectures where the code that would need to be generated to check for that case would have a 300% performance overhead<p>See my sibling reply down-thread. You don&#x27;t want the compiler to automatically insert the check; but neither do you want the compiler to assume you want to <i>not</i> insert the check. You want the compiler to error out until you tell it <i>whether or not you want a check</i>. Or rather, whether you want checked-division <i>semantics</i>—which will be free on some architectures and costly on others—or unchecked-division <i>semantics</i>—which will be dangerous on all architectures, but technically impossible on some (presumably, it would be approximated by using checked division and then throwing away the error.)<p>Either way, you probably <i>don&#x27;t</i> want the default &quot;checked division that could error out on the architectures where it&#x27;s free, and unchecked division on the rest&quot;; you then have to code for <i>both</i> the case where your function can now trap&#x2F;throw an exception, <i>and</i> the case where control continues through your function using the invalid calculated intermediate as input for further operations. You&#x27;ve probably coded to handle one or the other—but it&#x27;s very unlikely you&#x27;ve coded to handle <i>both</i>. And why would you want to have to?<p>Deciding on your code&#x27;s semantics should a development-time decision. The compiler should prevent you from <i>making the mistake</i> of leaving your code&#x27;s semantics to the whims of the target architecture your (presumably portable) code happens to get compiled on, at some other time by some other person, unless you <i>explicitly opt in</i> to having the semantics of &quot;whatever the target architecture wants to give me&quot;, on a case-by-case basis. The compiler should ensure that your code has the <i>semantics you want</i> everywhere—whether those be &quot;always do X&quot; or &quot;do whatever the target arch&#x27;s closest approximation to X is.&quot;<p>What we call &quot;undefined behavior&quot; in C is actually implemented by C compilers as a very specific set of assumptions about what semantics developers prefer—and those assumptions may or may not be right for <i>most</i> code, but they can&#x27;t be right for 100% of code. Code is made of decisions[1]; the whole of the task of programming is to explicate every decision about a business-process that was previously left implicit, so that the same predictable and deterministic thing will happen everywhere, every time. So why should compilers allow programmers to leave their desired semantics implicit?<p>[1] <a href="http:&#x2F;&#x2F;siderea.livejournal.com&#x2F;1241996.html" rel="nofollow">http:&#x2F;&#x2F;siderea.livejournal.com&#x2F;1241996.html</a>