Well you can't have your cake and eat it too ;)

> 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;
    }

And you call that function with const parameters:

    int c = add(2, 3);

Then you want that entire function call to be removed and "folded" into its result 5, and when this was the only place the function was called, you'd also want the actual function to be removed from the binary (because what's the point of lugging code around in the binary that's guaranteed to never be executed).

▲ vbezhenar 28 minutes ago | parent [-]

The "code" is `a + b`. The rest is just decorations.

Here's example from article:

    static int f(int a, int b)
    {
     x = b ? 42 : 43;
 return a/b;
    }

Compiler can inline `f` but if it removes conditional branch, that's where issue is. I wrote this branch because I expected `b == 0` to be a valid value. Compiler deduced that it can't be a valid value and decided to remove `43`. That's understandable. But let me know, so I'd rewrite my code myself instead. Because I have assumptions and compiler have assumptions and these assumptions do not match. It means that there's a bug.

	▲	masklinn 11 minutes ago \| parent [-]
		So you expect the compiler to tell you every time it inlines a function with a null check in a function which already had a null check on the same value? 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 non-zero and the check is redundant? As flo told you, if you want a non-optimizing compiler use a non-optimizing compiler.