Hacker News Reader

> UB problems happen only when compilers detect it, understand it is an opportunity for optimization, because they are allowed to do anything, then do that optimization.

This is a deep misconception, and not at all how most undefined behavior is related to optimization.

Trivial example: Compilers assume that your variables aren't written to randomly from other threads. Without this assumption, virtually no optimization would be possible. Therefore, data races are UB - they violate a hard assumption of the compiler. But at no point did the compiler say "oh, you wrote to this variable without synchronization! Now I'll show you, hehehe!".

This is the same for e.g. removed overflow checks. Compilers can optimize many loops only if they assume signed integer overflow never happens. So, because compilers should be able to assume this, it is UB if it happens in your code. The same logic that deduces "this loop cannot wrap around" deduces "this if condition [an overflow check] cannot ever be true".

But it's easier for a programmer who got their UB-reliant checks optimized out to attribute malice to the compiler than to understand optimization fundamentals, and thus we get people complaining to high heaven and back.

>But at no point did the compiler say "oh, you wrote to this variable without synchronization! Now I'll show you, hehehe!".

That's because the compiler doesn't detect the situation. If it knew, it could, say, remove all code leading to that point - it's legal and the resulting code would be faster.

>Compilers can optimize many loops only if they assume signed integer overflow never happens.

I don't think this happens. Most loops iterate over arrays, and at least in C tradition unsigned integers are used as array index with no signed integers in sight.

You are strawmanning the parent, he did not claim that compilers will go "oh, you wrote to this variable without synchronization! Now I'll show you, hehehe!". Your description of the compiler's behavior matches his description; the compilers detect a case where the program might exhibit behavior defined ISO C spec (signed integer overflow), see it as a potential for optimization because they are allowed to do anything (certain passes can be made if overflow is assumed not to happen), then do that optimization.

The parent said

> UB problems happen only when compilers detect it, understand it is an opportunity for optimization, because they are allowed to do anything, then do that optimization.

Perhaps I'm misunderstanding the comment, but I took "detect it, understand it is an opportunity for optimization, because they are allowed to do anything, ..." to mean "detect that undefined behavior occurs and then ..."

Instead, it should be "detect that an optimization can be applied and that the optimized code will do the right thing in all cases that undefined behavior does not occur, and apply the optimization."

I've met programmers who seem to believe that compilers intentionally apply weird transformations when they detect undefined behavior. But really, the compilers are applying sensible transformations for well-defined code and ignoring whether those transformations are sensible for code that isn't well-defined.

Here is an actual example of taking advantage of UB behavior in a compiler.

The compiler sees a variable x that's allocated on the stack. It looks at all the uses of the address of x, and sees that they are all loads and stores. It therefore decides to promote x into a register variable.

Where's the UB, you ask. Well, since the address of x was never leaked, it is UB to compute another pointer to that address (say, via an integer-to-pointer conversion). The compiler never checked for that possibility to affirm that it was UB; it knew that any code that did that would be UB and simply ignored the possibility.

This makes arithmetic overflow a very poor vehicle for UB because it's unusual in that you can't really take advantage of the UB without pointing to the specific operation that caused the UB to occur. This is why I believe that arithmetic overflow UB is gratuitous, and people objecting to UB because of what happens specifically with arithmetic overflow go on to make suggestions that are completely untenable because they don't have familiarity with how most UB works.

Undefined signed overflow isn’t great (and it doesn’t help that C’s implicit integer promotion rules are bad), but it’s important because it allows loop optimizations, which really are important cross-platform, eg Intel is fine with loops counting up but PPC would like them to count down.

The problem causing this is that C loops are overspecified. If there was a “for…in” loop that didn’t make you declare and increment a variable, then manual increments could trap on overflow without causing so many problems.

I don't understand.

If you can turn the loop from upward to downward then you do have a bound for it, and then you can tell if it overflows or not.

Also why is signed overflow a problem and not unsigned?

Surely you want unsigned loop optimized also?

Unsigned overflow is not UB (it wraps) so it has to be preserved more often, which means you have a loop bounds less often, which means those loops can't be optimized.

Typically not a problem for i=0...n loops but eg `for (i=0;i<n;i+=2)` could overflow.

You can cast literally any optimization into this shape. For starters, virtually any optimization pass requires sane assumptions about (absence of) data races and/or out of bounds writes. The point you are arguing (or claiming OP argued) boils down to "compilers behave as I want when I turn all optimization passes off".

No, the OP wrote specifically that "the compiler detects [UB]" and then does optimizations exploiting that. Not "detects potential UB". The former is a common misconception, the latter is basically a truism.

> You can cast literally any optimization into this shape

Tell me how these use UB: integer constant folding, unused load removal, optimal use of GP registers to minimize stack spilling

>sane assumptions

"sane" here is doing a lot of work. Assuming overflow won't happen is not a sane assumption, assuming some other thread won't randomly write into your stack memory is.

> unused load removal

Oh come on, this is like the most UB-centric thing in the entire compiler. The compiler uses UB to know that it has enumerated all uses of a memory location, as any pointer that didn't get its value from the data dependency tree that compiler used had to use UB to compute the address. (Be it from buffer overflow, use after end-of-lifetime, random integer converted to pointer, etc.)

I might be using the wrong terminology, what I'm talking about is removing e.g. `int x = *ptr` where x is then not used in scope (more realistically, `(*struct_inst).member` shouldn't bother to load the other members of the struct). What you're doing sounds like removing a global it detects is never used, which I agree relies too much on UB and should not be done.

Aside from the possible trap ("segfault") mention in the sibling comment, the first example relies on absence of UB because with UB you could enumerate the contents of the stack to find where `x` is living, and discover it isn't there, contra the spec. Even allocating variables directly into registers and never onto the stack relies on UB.

Why is it UB to use registers to store variables? This seems like an implementation detail. The ISO C spec doesn't even have the word "stack" as far as ctrl-f can show me.

> Why is it UB to use registers to store variables?

It isn't; that sentence is even a type error. UB is not a property of compiler output. It's a property of compiler input.

The use of registers to store variables between uses (when those variables never have their address taken) relies on the lack of any defined behavior which would allow the program to determine this is being done. The fact you can't find this in the spec is precisely because it is not defined.

If any object can potentially be reached by forging pointers or enumerating all memory locations, you can't even keep local variables in registers around potential stores to unknown pointers (or ever, in a multithreaded program).

Removing a load is visible behaviour if the load would have trapped for example.

Everybody agrees that compilers should only do sane optimizations. Nobody agrees on which subset is sane.

That's fair, I'll concede that I make some implicit assumptions. But the magnitude of people who hit problems and accidentally hit UB should give a strong indication that a lot of things done now are not close to sane.

Lobbying the standard body to reduce the amount of UB in the C standard is a perfectly reasonable position. Requiring compilers to DWIM is not.

> integer constant folding

    int a = 10;
    int var1;
    int b = 20;

    foo(&var1);

    int c = a + b;

You'd like to constant fold c? Better assume no UB:

    void foo(int* x) { *(x-1) = 0; }

> unused load removal

Same idea as above.

> Assuming overflow won't happen is not a sane assumption

If the alternative is loops being much slower when you request optimizations, then maybe it is. Consult your compiler manuals if this default irks you.

Okay, yes, you are technically right. What I mean is, making an assumption _other than_ that the code won't alter stack/heap/instruction memory that the implementation is using (e.g. aliasing, overflow, use of NULL)

Sorry, I'm tired of playing whack-a-mole with what are obviously sane assumptions to you. I literally mentioned out-of-bounds writes as a "universal UB" example, you asked me to demonstrate how UB is relevant in a few optimizations, I did, and now you shift goalposts.

My original point was that compilers don't specifically abuse UB to sleight you. You're trying hard to draw a line in the sand between different degrees of UB so that you can label one side as "not sane", with (what appears to be) the sole intent of concluding malice on the compiler author side. Please accept that the related tradeoffs have been discussed, and that a default was chosen (if you are curious for a recent instance of this, see [0]).

If you are ok with leaving performance on the table by disabling overflow being UB, you are literally free to do that. You're also free to lobby the standard bodies to alter their carefully considered choices. But you're not going to get anywhere by labeling any of this "insane".

[0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...

Isn't TBAA exactly the assumption that the program won't alter the stack/head/instruction memory in an illegal way?

That's not true at all. Compilers can detect some instances of UB, and they will happily warn when they do.

Most instances of UB are ones that the compiler could not detect. Your compiler isn't going to detect that your integer overflows, it assumes that it won't. Shit blows up if that assumption was wrong.

If you want to detect UB, you should run ubsan and the like. The compiler is not running it.

In some sense, the problem isn't that the compiler "can't" detect that an integer addition will overflow. The problem is that with some exceptions (a loop that is clearly indexing along an array, for example), the compiler will have to flag every integer addition as UB. UB notifications aren't that useful if you're getting a dozen for every five line function in your entire codebase.

Programmers do not, in general, want to do the amount of work it takes to safely add two numbers together. You need something "weird". Like an error path for every addition. Or a type system for ranges, where you actually have to specify ranges (because adding two bytes together that you casually left as 0-255 will create a new ranged value 0-510; multiplication is even more fun). Or some other exotic idea. So we just let them overflow and the chips fall where they may.

> In some sense, the problem isn't that the compiler "can't" detect that an integer addition will overflow.

It absolutely can't if it doesn't know what the values are going to be.

> the compiler will have to flag every integer addition as UB

No, I disagree. If it has no knowledge of my runtime values, it can't flag addition as UB because it isn't. It's UB only if I'm using values that would overflow, and the compiler in general can't know that. If I've done my program right, it will never overflow. There is no UB, any flag would be just absolutely wrong. The compiler couldn't detect UB. There's nothing to flag.

If it knows the values, then of course it can detect it and flag it:

    x.c:3:18: warning: integer overflow in expression of type ‘int’ results in ‘-2’ [-Woverflow]
        3 |  int a=2147483647+2147483647;

> Programmers do not, in general, want to do the amount of work it takes to safely add two numbers together.

I agree that overflow-checking is needlessly sucky in C but that's not "the problem." I usually make sure my arithmetic is safe but the compiler won't know it.

It blows up, but not as violently as when the compiler adds fuel to it.

UB is closer to "we assume this can never happen and make decisions accordingly" than "Ha ha, I caught you making a mistake, let's actively try to mess up your life now."

They know they mess up, they just have defense for it.

The problem is that this doesn't mean anything, at least in terms of the C programming language. You say "When integers overflow, they do that and nothing else," but there is no definition of signed integer overflow, so there is no "that" for them to do. That is what it means for something to be undefined behavior. You have some definition in your mind, which might happen to match what some versions of some compilers do at some optimization levels — but that isn't actually the definition, because there isn't one.

Wrapping arithmetic is supported by gcc and clang.

Reading uninitialized memory is not UB... but anyway. Here's an example of how compilers treat null dereferencing as UB:

    void func(struct x *aptr, struct x *bptr) {
        x->a = 5;
        y->a = 10;
        x->a = 10;
    }

This is a contrived example but you can imagine writing code that makes a sequence of assignments like this. An optimizing compiler can remove the "dead store" which assigns 5 to x->a. However, this optimization is valid because writing to a null pointer is undefined... if writing to a null pointer trapped (SIGFAULT), which is what it actually does at runtime, then the optimization would be incorrect... because you could observe the intermediate value of x->a = 5.

The compiler is not really "detecting that your program has undefined behavior". Instead, it is assuming that undefined behavior doesn't happen, and optimizes your program using that assumption. It's unclear what "detecting undefined behavior" would mean here... what kind of diagnostic the compiler should emit, or how to suppress the diagnostic. It's clear that this simple code is pervasive, and the preferred approach for dealing with it is somewhat outside the scope of a normal C compiler... something like static analysis, runtime instrumentation, or some kind of formal methods.

> However, this optimization is valid because writing to a null pointer is undefined... if writing to a null pointer trapped (SIGFAULT), which is what it actually does at runtime, then the optimization would be incorrect... because you could observe the intermediate value of x->a = 5.

I'm not sure this is a good example, because there's no way for you to read them from the same thread (and reading from another thread would be a race). Reading them from a signal handler would yield unspecified values (unless you're using lock-free atomic types, in which case we're probably not worried about optimizing these assignments).

> When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type volatile sig_atomic_t are unspecified, as is the state of the floating-point environment.

That's a good point, however I think it's not hard to come up with a different example that shows how compilers assume that pointers aren't NULL. Like,

    void function(struct x *ptr) {
        ptr->x = 1;
        if (ptr == NULL) {
            some_big_chunk_of_code();
        }
    }

The idea is that this could be the result of inlining, where the inlined code does a null check, but in the context it's being inlined into, we already know ptr is not null.

The compiler should help the programmer optimize instead.

"Warning: dead store detected (file):line clobbered by (file):line. Use keyword volatile to always store or remove (file):line."

This way the optimization is promoted from the resulting binary to the source code, and bugs / typos / etc can be corrected.

Optimizations often deal with inlined code. The code in the inlined function might be fine in the general sense, but once taken in a particular context, there's dead or redundant code because the compiler can deduce values from context. It might even all fold into a constant.

Telling the developers to optimize these would be equivalent to telling them to start inlining their code (or creating variants of every function that might be inlined, to optimize it for the specific context where it will be inlined).

That's a completely unworkable solution.

The above code isn't necessarily code as the programmer wrote it, but the code after it appears after macroexpansion and various optimization passes. If you were writing C++, the code may be templated.

You would get literally millions of such warnings on your average C codebase.

So basically you are saying that in the average C codebase there are millions of landmines waiting to silently fail on you. This is not a ringing endorsement of the language it's more like a ringing indictment instead.

I certainly do not think that each dead store which has been eliminated is a landmine, this is such an extreme position that it isn't even worth considering. In the very rare cases were I needed a store to actually happen I will use inline asm or some form of volatile.

Which coming back to the main subject isn't ISO C, rather a compiler extension.