I did say barring optimizations to ensure that that was taken into account. The link is a deterministic one, which is what matters. If the program would do something you did not program you'd see that as a compiler bug.
Newer languages consider this to be a misfeature, and have taken pains to define far more of the language semantics outright, even if the definition is simply "This is a compile error" or "This is a panic." It's interesting that we're now going back the opposite way with LLMs, with their ability to generate code that does something for any natural-language prompt being a major selling point.
Plus, these undefined behaviours are well-documented, even if easy to miss.
Whereas in LLMs, the whole thing is undefined behavior.
Bingo!
When you exploit undefined behavior using a compiler, what do you do? You verify that its output, the object code, does what you intended with the undefined code. Or else you at least have to test the heck out of it.
Gee, what is all that similar to ...
All observable and defined side effects should be identical otherwise you have a compiler bug. Optimizations that are not generically semantics preserving may be used, but should only be used where the program is semantically identical for your use case otherwise you have incorrectly used the options available in your compiler.
For example a JIT compiler can produce completely different kinds of machine code depending on the application data that was processed, and the overall machine workload.
The output program does what the input source code does. The abstraction is a precise translation and non-leaky, it just admits multiple possible internals. That does not make the translation any less precise.