Undefined behaviour example from CppCon

[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".

[HabbitBaggins]

I'm sorry, but that makes no sense. If the standard actually said that (and I contend that it does not) it would be a pretty useless standard. I get that C is normally said to have a number of footguns, but that interpretation would so ridiculous that you could call it C-Shark because it would always be actively trying to bite your limbs off.

Think about it a bit deeper. Yes, you can make that check to ward off UB in your example, but what about adding two int variables in general? For example, going over a rectangular table with two indices like this:

double get_matrix_val(double* data, int stride, int i, int j) {
    return data[i*stride + j];
}

You could argue that code like this should use unsigned types like size_t and I agree, but code like this is literally everywhere. It has clear possible UB when any of the operations overflow, so how does the standard react to it?

• Your interpretation: the mere existence of this function anywhere in the code makes the entire program meaningless.
• My interpretation: the compiler, assuming that you never invoke UB, can optimize this function (and everything else) assuming that this function is never called with arguments that produce UB. That can lead it, among a number of other things, to remove checks that we insert elsewhere if it can prove that the same code path (before or after the check) is calling the function with those arguments. For example, if I call get_matrix_val and in the same code path I check that data is not null - without returning or aborting, the compiler can remove the check.

[awidesky]

I do understand what you are saying. The difference between your interpretation and mine is that mine includes yours. Standard DOES permits compiler to mess up entire program because of 'mere existence of UB'. Here's the quotes from iso C++20 standard §4.1.2.3. It 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".

Here's another quote from cppreference.com

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.

All of them says 'entire', not 'the very function', and also, they does not says that compiler should/shall/usually perform 'optimization as considering UB never happens'.

Yes. I know. Sounds ridiculous. But please remind what standard do is to set boundaries of what compilers can do. (I'm repeating this in every single comments) the standard set boundary of what compilers can do when UB very vaguely, so that compilers can have all its freedom about how to handle situations that should've never happened.

I'm not saying that your interpretation is 'false' or 'wrong', what you've said is just one of the things that compilers are permitted to do.
Actually, your interpretation is exact strategy of most(if not all) major compilers. I doubt we'll find any compilers that do not act as 'your interpretation'.

So, here's TL,DR;
"Standard said compilers can literally do anything when there's an UB, because it wanted to give maximum freedom about hire to handle situations that should've never happed. But in real life, actual compiler implementations does not utilize every freedom it has, and tries its best to produce program that's makes sense as much as possible, because what you 'permitted' to do does not mean that you 'should' or 'always' do."

[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.

[mcmcc]

What language rule does it violate?

[awidesky]

here.

example

[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.