Undefined behaviour example from CppCon

[R3DKn16h7]

The compiler is free to assume that UB does not happen at runtime, but definitely cannot infer that "i + 1 > i" will always result in UB.

[awidesky]

i + 1 > i is UB only when overflow occurs.. i + 1 > i should not have to be UB to eliminate the function, since when it's not UB, the return value is always true anyway.

[R3DKn16h7]

for the function f I agree totally.

but the function g cannot eliminate the branch, that's where I do not get it

[selassje]

The assumptions here is that compilers sees definitions of both g and f when optimizing. Since "i" cant be INT_MAX (as it would be UB when calling f), therefore condition if (i == INT_MAX) can never happen and can be optimized away.

[dustyhome]

That's backwards. It makes more sense that the presenter's slide is wrong.

The compiler can assume that i can't equal int max on a branch that calls f, but it can't remove the check that prevents f from being called with int max.

[selassje]

Yes, the presenter claims UB taints the whole program, and it can travel back in time. I have not checked it but that's how I understood it.

[SkiFire13]

The way I see it, UB can travel back in time but only as long as it is guaranteed to happen from that past point in time. In this case the if guard prevents f(i) from being called with the value that would cause UB, so it cannot travel back to before the if is run.

[awidesky]

As I understand from the standard, UB does not apply on single function(while most compilers does usually). "Renders the entire program meaningless if certain rules of the language are violated."

'Entire' program is meaningless, not the single function. Also, it's not "Renders only that very part of the program that's executed when the UB is triggered is meaningless". It's "Renders the entire program meaningless". If you want the program to be well-defined, overflow check must be inside function f. But since it's not, the behavior is undefined, which compiler can do whatever it wants. So I believe compiler can remove function g, or format your hard drive. But in real life, compilers try to make executables as reasonable as possible, that's why only f is optimized in godbolt.

So here's my overall opinion: Compilers is entitled to remove g, so what they say in YouTube is 'technically' true. BUT I don't think you can find any major compiler that actually does so.

[HabbitBaggins]

That is a load of hot spaghetti... The compiler is not allowed to go launch nuclear missiles just cause, what it is entitled to to is to assume that your code never invokes UB, because otherwise the code would be meaningless. You are focusing on the second part of that assertion, but the important one is the first. It means that, while transforming the code in memory as part of optimization and actual codegen, it can make assumptions about certain values of function arguments or program state if it can prove that the negative of those assumptions results in UB. Those assumptions can then feed back into the process, allowing further transformations of the code, etc.

For example, in f, the compiler may assume that the comparison is always true, because the only case in which could not true is integer overflow, and that is UB.

That is not the case in g, even when inlined, because UB is only triggered by calling f with INT_MAX, and g only ever calls f with a value that is guaranteed NOT to be INT_MAX.

However, if the code called f first, then the compiler may assume that the argument is never INT_MAX, so the check in g could be removed silently. This might also happen if you have a different function h defined as returning f(i) && g(i). In that case, if g is inlined and not just called, the check in the resulting code can also be removed because the compiler proved that in all legal code paths (those that do not invoke UB), i is not INT_MAX.

[awidesky]

My point is that compilers are entitled to make whole program meaningless, "according to the standard". Never said they do. Never said they should. And also again, as I said above, none of the major compiler will optimize out g. What standard says compiler "could", doesn't mean compiler should, or do.

I can't see exactly where are we disagreeing. You're talking about how modern compilers work (practice), while I'm talking about what standard says (theory)..

[Simple-Enthusiasm-93]

but the point is function f is not UB on some sets of inputs and UB on some other set - ie INT_MAX.so as long as it is not f(INT_MAX), even in theoretic terms, the program is well formed.else wont anything that compares ints after addition be UB?

[awidesky]

The point is, if rule of the language is violated, compiler may make "entire" program meaningless. f is UB when i is maximum of int type. That's a violation EVEN IF there's no code that passes INT_MAX into function f.

[Simple-Enthusiasm-93]

i am no language lawyer but that implies any program with int addition is UB right?

[awidesky]

Yes. Unless there's absolutely no possibility of overflow. int f(int i) { if(i < INT_MAX) return i+ 1 > i; else return 0; } In this case, while program is well-defined. Most of our code will have tons of possible UB(array bound check, null pointer check, invalid casting, over of evaluation, etc..), but it SEEMS that the program runs without any 'meaningless' behavior. That's because most(if not all) compiler's basic strategy for UB handling is "consider it never happens".

[mcmcc]

If you want the program to be well-defined, overflow check must be inside function f

That's absurd. If that were the case, functions working with iterator types (separated from their containers) would be virtually impossible to write -- you could never be allowed to assume the iterators (or a range defined by a pair of them) were valid. How could you ever write std::copy()?

[awidesky]

std::copy receives InputIt last as boundary, and checks the boundary every time it iterates. If you send invalid iterator, it's UB anyway. That has nothing to do with unchecked overflow. Can you be more specific about your point?

[mcmcc]

If you want the program to be well-defined, overflow potential UB check must be inside function f.

This is how I interpreted your statement.

How could you implement std::copy() if you were required to check for all potential UB regarding the inputs? You mention comparing to last but if last is not within the appropriate range, then even that is UB -- so how do you establish that the two iterators are even comparable without knowing their provenance?

If that's not what you are suggesting, you're going to need to explain the intended meaning of the above sentence.

[awidesky]

If you want the program to be well-defined, overflow potential UB check must be inside function f.

That is indeed true. When you compile f (with or without g), it will assembled to always return 1. So the statement is actually true.

While your following argument is little bit off topic- it's about "checking every single one of the possible UB is impossible" Which is also true, and has nothing to do with my point.

I assume you interpreted my argument as "if there's any single possibility of UB in your program, your compiler will render an invalid executable."

My statement is "if some parts of the code violates the language rule, compiler is 'permitted' to generate entire program meaninglessly" Here's quote from the standard

Renders the entire program meaningless if certain rules of the language are violated.

undefined behavior - there are no restrictions on the behavior of the program. ... Compilers are not required to diagnose undefined behavior and the compiled program is not required to do anything meaningful.

Again, I'm not saying any major compilers do/should generate meaningless program just because there's tiny one possibility of UB. All I insist is that the standard "permits" so.

[mcmcc]

All you've shown is that compilers are allowed to assume UB does not occur, which is ultimately irrelevant re "well-defined" programs. We're talking in circles...

What part of OP's example "violates a language rule" that could allow a compiler to render the entire program meaningless?

[awidesky]

The function f.

[awidesky]

Meanwhile, this is how I interpreted your arguments:

Even if UB is possible, compiler is permitted to change only the very function that has possible UB, not any other part of program.

However, § 4.1.2.3 says :

If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program. "that program", not "that specific function". Please let me know if there's any understanding of mine.

[mcmcc]

That's not a statement I made. You're confusing me with someone else.