The resulting performance difference is basically the price to pay for such a 'strict' compiler which translates the input source code straight into machine code instructions without attempting to simplify the output code via inlining, constant folding and dead code removal.
> Dead code removal is unexpected by the programmer, because programmer does not write dead code.
Of course it is expected, because the optimizations leading to dead code are fundamental for the performance you get out of a release-mode binary (and that's also true for languages with less UB like Rust btw).
When you have a function:
static int add(int a, int b) {
return a + b;
}
int c = add(2, 3);
Here's example from article:
static int f(int a, int b)
{
x = b ? 42 : 43;
return a/b;
}
Because as far as it’s concerned that is the same thing.
Both clang-tidy and sonar will flag this since it’s broken on its own, but when you’ve fixed it you want the compiler to warn you every time this is inlined in a function where b is known non-zero and the check is redundant?
As flo told you, if you want a non-optimizing compiler use a non-optimizing compiler.
Dead code elimination is like the single most profitable optimization in the compiler, especially in conjunction with inlining and constant propagation that makes several branches become trivially dead. And its removal is very much expected by programmers, because (for example) bounds checking tends to work by generating bounds checks for every possible array access and relying on the compiler to be able to prove most of those bounds checks redundant.
No, my suspicion is you're actually only against certain kinds of dead code removal, but the kinds you're against are so inconsistent that it's impossible to implement a decision program except by including a routine to read the programmer's mind.
DWIM is not a spec.
Usually it means GC, bound checking and no pointer forging.
Plenty of literature on the matter, some retro computing fun, or using some of the survivors in modern platforms, for example Ada.