The problem here is, as you point out, the conversion of double to unsigned byte.<p>More specifically, the problem is that processing this operation is not producing error; it instead propagates the problem and produces invalid code. That&#x27;s a situation where nobody wins.<p>I think we&#x27;d be better off if many undefined behaviours were instead implementation defined. If, instead, LLVM had converted the double to some integer and then chosen the lowest 8 bits from that integer, we&#x27;d have gotten some random value - but at least the comparison wouldn&#x27;t have been ignored. The comparison should only be ignored if the compiler can prove that the value definitely lies within the range; if it isn&#x27;t sure, it can&#x27;t remove the comparison. The programmer wrote it for a reason; ignoring the intent of the programmer is a bug.<p>On strict aliasing, I&#x27;m against it without explicit opt-in over a delimited subset of source code. I understand that using &amp; is going to harm the performance of my code; I think that&#x27;s an acceptable tradeoff for more predictable behaviour. If it harms the performance of C++ vector iterators, for example, I don&#x27;t care: strict aliasing rules are a worse cure than the disease of C++&#x27;s poorly thought out abstraction tools. Let a subset of the program follow Fortran rules if it&#x27;s required.