Hacker News Reader

Comment by jakobnissen | Hacker News Reader

This is completely infeasible. A C compiler makes so many assumptions that UB does not occur that every program, even well functioning ones, would emit walls of warnings. Also, these warnings can't be silenced. Consider the integer division case: Should the warning be emitted every time division by zero is encountered at runtime? In that case, C would be much, much slower. Or should the compiler emit the warning whenever it can't prove at compile time that the divisor is not zero? In that case, you would get tonnes of situations where you can't fix the issue because you can't prove to the compiler it's not zero. Division by zero is a easy case. It gets much harder to emit warnings for aliasing assumptions, for example.

View on HN

I'd say the alternative is the rust approach. of debug mode always doing checked div and checked add ops. this prevents a large class of issues which you can find in debug mode. In release mode those UB checks are dropped. You of course can specify the type of add you want i.e saturating or wrapping etc. But yeah it makes things slower but the alterative is the code potentially doesn't work. Linux is funny in this regard which i think is why Linus allows rust and not c++ because potentially not working is a big deal in a kernel. C++ doesn't address this issue and of course C does not C++'s potential UB space is so much bigger because of alliasing issues and object patterns exposing more chances for UB.

Regardless you are right there is a cost is it worth paying hard to say

> of debug mode always doing checked div and checked add ops. this prevents a large class of issues which you can find in debug mode. In release mode those UB checks are dropped

Checked divs are present in release mode too. Omitting them would be UB.

Other checks (e.g. for additions) are omitted in release mode, but they were not preventing UB in the first place because they guard a wrapping addition, not an unchecked one (the kind that's UB in C).

The compiler should emit a warning at compilation time, when it decided to replace the conditional with single branch, throwing away the condition itself and the second branch.

If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler. If that expectation was wrong, compiler should inform me about that.

> If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler.

It's very common to write code in templates or inline functions expecting the compiler to remove it if it's not relevant on the calling site. That's part of what makes "zero cost abstractions" have zero cost at runtime.

For instance, I have a SIMD routine with extra code to process the tail (leftover elements smaller than the native vector size). When the compiler can prove that the size of the input will always be a multiple of the vector size (which is very common for my use cases), it will completely remove that tail handling code.

They you'll see that warning and mark your extra code to remove that warning, because you're aware that it's subject to potential elimination.

I think the point is that your code will light up as a Christmas tree, since basically anything could be eliminated in specific contexts. For example, the loop that handles vector-width parts of the array can also be eliminated (as in the condition/branching). If the compiler can prove that there will only be a small, fixed number of iterations, it will just unroll the loop.

> If I wrote some code, I expect it to be present in the binary.

That's oversimplified. If after inlining and constant folding an if-condition turns out to be always true or false I would definitely expect that the compiler removes the dead branch.

This type of optimization is the base for the fabled "zero-cost-abstraction" (which isn't only a C++ thing, C code depends on it just as much), and removing those optimization would seriously tank peformance in any non-trivial codebase.

How about if the compiler translates a pointer deference into a read of that memory address? That is potential undefined behaviour that has been "optimised" into something simpler than a safe operation (tracking all memory allocations and checking if the pointer is correctly pointing into one of them). So every pointer deference would also generate a warning (except perhaps where the compiler can prove from local information that it's safe).

It is definitely a hopeless path.

Turning off all arithmetic simplification is a wild choice.

Suppose you have the following program:

unsigned f(unsigned x) { return 2*x; }

Can this be optimized to instead perform a bit shift? That's faster than multiplying. But you wrote a multiplication operator. Should the compiler be responsible for keeping it?

> A C compiler makes so many assumptions that UB does not occur that every program, even well functioning ones, would emit walls of warnings.

The problem here is that the C compiler ever assumes that UB doesn't happen. That is empirically very much not the case, therefore the compiler should never be allowed to assume a lack of UB unless it can somehow prove that to be true. I honestly don't really care how many optimizations that would break; correctness is king. Software that goes fast is only worthwhile if it works correctly.

> I honestly don't really care how many optimizations that would break; correctness is king.

It's approximately all optimizations. Good news: there's already a compiler option that does exactly what you want: -O0. It's even enabled by default (unless overridden by another -O switch)!

-O0 code also omits a lot of "Don't be very stupid about it" optimizations, it's not a realistic option for much production code.

A surprising number of those optimizations are only valid by "reasoning from undefined behavior".

Under the as-is rule, optimizations must not change program behavior. A C program could theoretically use out-of-bounds pointers to scan its own stack, observing whether a value occurs on the stack. Thus, the as-is rule prohibits storing local variables in registers!

But because out-of-bounds pointers are undefined behavior, the compiler can ignore the programs doing stack scanning, and so register allocation becomes possible under the as-is.

So boring old register allocation is one of those "assume that UB doesn't happen" optimizations! Of course, the compiler never actually reasons "this pointer arithmetic is out of bounds therefore I can put that variable over there into a register" -- the reasoning from undefined behavior doesn't happen at compile-time, it already happened when the "register allocation" optimization was designed. But that's the case for most "assume that UB doesn't happen" optimizations! (this is also why it's so difficult for compilers to warn about undefined behavior -- they optimize based on it without ever detecting it!)

If you want to eliminate "reasoning from undefined behavior", you'd also need to replace the "as-is" rule with something else -- an explicit list of allowed optimizations in the language standard?

Indeed. No UB is something no mainstream C/C++ compiler does (and maybe ever did). Benchmarking the performance impact will require basically rewriting GCC or LLVM, an insurmountable task, because the assumptions are so ingrained.

Though it might be possible to have more "sensible" UB. For example, assuming daemonic non-determinism for allocation address it is possible to turn stack storage into registers, without the need for an aliasing model. Benchmarking it has the same difficulty.

The problem is really surprising UB. I don't think that an experienced C programmer blames the compiler if some pointer offset trick to manipulate variables on the stack stops working. Compilers used to be "less smart", so they didn't get too clever about UB neither. Now they do and it surprises developers. That is a real problem.

A challenge is that it doesn't seem like people agree on what "surprising" UB is. I don't think it would be totally unreasonable to have a compiler mode that specifically assumes that all arithmetic operations are total functions, which covers many of the scenarios that show up in blog posts. But there is somebody in this comment thread who is upset that you can't read from an uninitialized heap address to obtain unpredictable data.

My personal observation is also that it only surprises developers when they read blog posts about it and that this actually comes up quite rarely in practice.

s/as-is/as-if/

You are otherwise correct of course.

> The problem here is that the C compiler ever assumes that UB doesn't happen.

Imagine you have a tail-recursive function and you'd like to convert it to iteration. This is only semantic preserving if there is no UB!

Or worse, if you can never assume that UB doesn't occur then you need all code to be compiled in a way that defends against data races. You can't change the allocation order on the stack, since there might be some write past the end of a buffer and now suddenly stack allocation order changes the semantics of the program. Nightmare.

Imagine this program:

    int f() {
      int x = 1;
      a(x);
      b(x);
      return x;
    }

Can we use constant propagation to replace "x" with 1 in the instructions? No. After all, a could smash the stack and write over x. You need a new read of that memory location every time you plan on using x.

Reply on news.ycombinator.com