Hacker News Reader

Comment by BeeOnRope | Hacker News Reader

Dropping "explicit error checks" is no doubt bad from the user's point of view, but the primary difficulty is that to the compiler, working at the abstract level of multi-pass optimization of the IR, the good and bad cases all look the same. Pruning paths that lead to UB leads to some significant actual real-world optimizations (and these extend beyond these various signed-wrapping examples), and people want those whether they know it or not. Unfortunately, to the compilers, your overflow check just looks like another one of these cases.

That is, it is very hard for the compiler to guess the programmer's intent, and say "oh, this is actually a check which is trying to avoid overflow, and despite that it uses UB, we should compile this part with wrapping semantics instead", and yet apply the optimization in all the other places you would want it. You could probably come up with some type of pattern recognition, or some heuristics like "if the optimization makes some of the original source code dead unconditionally, don't make it", but I think this is both very difficult and in many cases worse than the current disease.

I think you can make a strong argument that the optimizations enabled by some types of UB exploitation are not worth the bugs and vulnerabilities they cause, and so the UB should be removed entirely, making it defined or implementation defined. Trying to have your cake (yes, it should still make these optimizations x and y) but eating it too (oh, but case z is different, see?) is a tougher proposition.

View on HN

Dropping "explicit error checks" is no doubt bad from the user's point of view

Only from the user's point of view? No, I'd say it's bad in some absolute sense as well.

Can we at least agree that it would be better for the compiler to do what the programmer clearly intended? Yes, given current limitations, it can be difficult to see how a compiler has enough information to always recognize this intent. But I hope we at least both agree that if all else doing equal, doing what the programmer meant is the preferred choice?

As a parallel, I think the approach of having -Wall flag "if (a = b)" as a likely error but be overrideable with "if ((a = b))" is a great solution. Maybe this one can be solved with an extra block, or with a better #pragma, or just really good heuristics. But the current approach of silent deletion of explicit code for undefined behavior is a terrible pattern!

> Only from the user's point of view? No, I'd say it's bad in some absolute sense as well.

I didn't say _only_, but I'm not sure about "bad" an an "absolute" sense. I think it would take a lot of defining the exact question to debate that. For me if it is a bad outcome from the user's point of view, it is already worth discussing.

> Can we at least agree that it would be better for the compiler to do what the programmer clearly intended?

I guess? It would be pretty neat to work in a language that did what I intended rather than what I wrote, but it will quickly become unsustainable when two people write the same code but intended different things.

That problem doesn't apply exactly here since the code is just UB, so the intent doesn't exactly conflict with the actual semantics since there are no semantics. However, the compiler writers have decided to chose the behavior which produces the fastest code.

> Maybe this one can be solved with an extra block, or with a better #pragma, or just really good heuristics.

IMO, it is largely already solved.

If you want signed overflow to behave as, well, signed overflow, use -fwrapv. You pay the small price in reduced optimization opportunities, but you get well-defined behavior on wrapping always (note: wrapping is still almost always a bug!).

I think you can make a good argument that this flag should be the default behavior. Certainly, if you were designing a new language you might want to make it the default and maybe C and/or C++ will get there some day.

> But the current approach of silent deletion of explicit code for undefined behavior is a terrible pattern!

This sentence embodies my main complaint with the endless discussions on this topic. There is no optimization that just removes signed overflows checks, inserted there by a malicious compiler writer. There is a big family of interlocking optimizations, which as a whole are responsible for some spectacular gains in compiled code efficiency. For example there is dead code elimination, which is really important. There is treating code that does something impossible or UB as dead, which is also important (it extends way beyond this signedness stuff).

All this conspires to eliminate the _explicit_ overflow check which is the poster-child for compiler misbehavior - but the same optimizations do all sorts of other stuff that you wouldn't have a problem with. Everyone points there finger at this case that looks bad and says "obviously don't do that", but very few explain how. Deep within the guts of the optimizer, you just have IR which probably looks nothing like the code you wrote, there is no distinction between explicit and other code, and no "annotation of intent" to tell anyone what the programmer _really meant_.

You have most or all of the major compilers implementing this optimization, yet none of them have apparently solved this simple case of not messing up what the programmer wrote? Probably because it is not at all simple.

The solution I'm aware of is to just always treat overflow as defined. I.e., the -fwrapv solution. I'd be fine if compiler makes made it the default - but I guess the competitive pressures mean that compilers generally leave all legal optimizations on at the highest levels, to not be slower than the other guy. I'm OK with that also - at least it's a consistent rule.

The compiler-writers position is if you write broken code that invokes UB, you don't get the complain. I think that's often a reasonable approach. In other languages it's just the obvious default: it's just a bit annoying in C/C++ because there are so many things that people think should work, and did work, but are actually UB.

There is a big family of interlocking optimizations, which as a whole are responsible for some spectacular gains in compiled code efficiency.

I agree with you on the "interlocking" part, and the lack of conspiracy, but is there a canonical example of these "spectacular gains"? Particularly, from an optimization that depends on the assumption that the program exhibits no undefined behavior, where the opportunity for optimization disappears if the undefined behavior were instead to be implementation defined.

You have most or all of the major compilers implementing this optimization, yet none of them have apparently solved this simple case of not messing up what the programmer wrote?

I do not assume that it is simple, only that it is important and desirable. I'm not sure if compiler writers believe it to be impossible to do things better than they do, or just not sufficiently desirable to make it worth the effort. My guess would be that it's impossible to obey programmer intent perfectly in these cases, but possible to do much better than is done currently.

The solution I'm aware of is to just always treat overflow as defined.

First, I'm using signed integer overflow as the example not because it's a particular focus for me, but because it was central to the examples of linked article. Rather than -fwrapv, my personal preferred practice is to avoid unnecessary use of signed integers. My actual focus is the larger group of optimizations thought to be possible only because one can assume that a program does not invoke undefined behavior.

I'd like to see C (and probably C++, although I've thought about it less) reduce the scope of undefined behavior, either at the level of the standard or of individual compilers. I think there is room to allow more cases to be architecturally defined without significant adverse effect. I think the counter-argument is that if this were done, performance would necessarily drop. I haven't yet seen proof of this.

It appears that many people seem to assume (as you seem to) that there is no room between "implementation defined" (-fwrapv) and "undefined behavior" (nasal daemons). What I (and I think vyodaiken) are arguing is that there is a level of compiler agnosticism and architecturally defined that can be a useful middle ground. I think this approach (at least for C) offers 95% of the optimization potential while going 95% of the way of honoring the "obvious" intent of the programmer.

> I agree with you on the "interlocking" part, and the lack of conspiracy, but is there a canonical example of these "spectacular gains"?

To be clear, when I spoke of spectacular gains, I meant the overall result of all optimizations that modern compilers make, not just the "controversial subset". To see that with pretty much any program, just compare compiling with and without optimizations, or perhaps compare against a 20 or 30 year old C compiler if you can find one.

The actual impact of this specific controversial signedness optimization is likely to be small overall, at best low single digit %s but likely even less over a complex piece of software. That's true of many of individual optimizations today. In this case, you can easily A/B test this by compiling with and without -fwrapv. I have seen plenty of cases where the difference is zero within measurement accuracy!

In unusual cases, the optimization might speed up some loops by 2x or 3x (an example at [1]), but unless that loop makes up the majority of your application, those speedups will be averaged out by a lot of code that doesn't change.

So this signedness thing is not at all an example of spectacular gains, and I didn't mean to imply that it was.

Outside of signedness, if you want examples of some significant gains by "exploiting" UB rather than making all behavior [implementation] defined, don't worry: there is no shortage. Just go through a list like [2] and then follow the discussions in many places (including proposals in the standards committees) about what optimizations each UB allows. Certainly not all of the reasons for UB lead to interesting optimizations, but many do.

Consider a simple example: deallocating (e.g., free() in C, delete in C++) the same memory twice is UB, as is deallocating memory that was never allocated. You could certainly make this well-defined or implementation-defined instead: just define it to return some kind of error indication or do be a no-op.

If you've ever tried to write a high performance memory allocator, you already know that this requirement will kill you. You'll have to be able to distinguish a valid pointer from an invalid one, and you'll probably have to implement your whole allocation scheme in a different way.

Despite invalid deallocation and the consequent heap corruption being a major issue pretty much across the spectrum of C/C++ software (way more than a few signedness quirks), you don't hear almost any wailing or gnashing of teeth about how crazy it is when these programs malfunction - it's never going to make the front page of HN.

Now, you are probably thinking that obviously they malfunction because they have a bug! They are violating the specification! Well, the same is true of the signedness stuff - it's just a lot more surprising and less expected because (a) it's a relatively new phenomenon (b) like many more people people are aware of the UBness of invalid frees than are aware of the UB of signed overflow (c) if the compiler compiled it in the "obvious" way on "my hardware" it would have worked!

To be clear, I think this allocation thing is a completely defensible example of UB. OTOH, I think given modern hardware, and the limited gains, the signedness thing specifically is less defensible: but the solution is there no matter which side you fall on given -fwrapv.

> Rather than -fwrapv, my personal preferred practice is to avoid unnecessary use of signed integers.

Interesting. I use the opposite approach: I try to use signed for all _numeric_ values (leaving unsigned for "bit strings"), because I'm quite sure that the number of bugs caused by the discontinuity at zero (for unsigned values) is much larger than the number caused by the discontinuity or UB at INT_MIN/INT_MAX. Avoiding bugs is my goal and when you "wrap" a value it's almost always a bug whether the compiler exploited it to do something weird or whether your program carries on with a semantically invalid value.

So I while I have heard this "used unsigned since at least it has defined behavior" thing many times, I think it is usually misplaced. Examine a bunch of integers in any program and decide whether the program is correct if they wrap: the answer is almost always no. Weird cases like this were something was specifically trying to detect a wrap and do something are lost in the noise.

> My actual focus is the larger group of optimizations thought to be possible only because one can assume that a program does not invoke undefined behavior.

I think it is a bit harder than you imagine to define the scope of that. Nearly any optimization relies on the absence of some types of undefined behavior such as wild writes: if you make wild writes defined behavior, you probably won't even be able to keep any variable in a register. You can get there, and still have good performance, but you pretty much need a new language (see Rust or Java, for example).

> I think the counter-argument is that if this were done, performance would necessarily drop. I haven't yet seen proof of this.

You only need one example, right? See [1]. That's just the last one I ran across and it's actually a new example, the other ones I saw were places where different assumptions could be made about the induction variable. The impact here is 3x the number of instructions in the loop body (ignoring overhead).

That said, I totally agree on reducing the scope of UB in the standard. A lot of the UB is here to stay, like wild reads and writes, double deletes, even (I suspect) strict aliasing. A lot of the other UB, however, is just a relic of the hardware around the time C was being standardized. There is little reason not to settle on 8-bit bytes, 2's complement arithmetic for signed and unsigned with the "expected" wrapping, arithmetic left shifts for signed values, etc.

The standard may eventually get there, but in the meantime people are already somewhat "opting in" to that world, simply by writing code that assumes a non-deathstation machine, i.e., not using CHAR_BIT, assuming intptr_t has the expected representation, etc. Adjacent standards like POSIX even define a lot of this: if you using POSIX a lot of the weirder possibilities go away because POSIX defines a bunch of things that are left open in the C standard.

> It appears that many people seem to assume (as you seem to) that there is no room between "implementation defined" (-fwrapv) and "undefined behavior" (nasal daemons).

Yeah, that's pretty close to my position on this issue. A more nuanced version would be that I am not personally aware of some middle ground that is better than the current behavior or -fwrapv. More to the point, I never see anything like that presented by the opponents of the current behavior (you have taken the step of suggesting that you think it exists - which already puts you in a small group trying, if barely, to explain how it should work). Most just the claim that the current behavior is really insane with the implication that there is some better way. Some just use and promote -fwrapv as that better way, but many reject it.

So what is this better way? You can go back and read various discussion on the compiler dev lists, as I did at one point, and you won't find this better way. These people are smart enough to get us into this situation, so one would imagine they'd be smart enough to least discuss this better way if it exists.

You can take a survey of other languages, most more modern and so with the advantage of hindsight, and see what they do. I don't see the solution there either. Of course, some use arguably _better_ behavior like 2's complement wrapping, like Java and probably a lot of others, but that's just -fwrapv. A lot use something heavier-weight like infinite precision integer, which probably wouldn't be appropriate for C/C++. Rust uses a kind of weird mix of wrapping in release builds or trapping in debug builds - I'm not yet sure how I feel about that one.

So yeah, you can put me down in the camp of not finding the position of the compiler writers all that unreasonable: they are following the standard, the programs that exhibit this surprising behavior are ill-formed (even if that is surprising), and critically they _offer a flag_ to reverse all of that so that signed wrapping is well-defined and then everything works.

I think the primary criticism one could reasonably level is that flag should be opt-out, not opt-in (i.e., wrapping by default).

A vague suggestion that there must be a better way, without details, I don't find all that convincing and I think it's reasonable for compiler people to more or less put the topic on the shelf until details are forthcoming.

---

[1] https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...

[2] https://blog.regehr.org/archives/1520

(out of order quoting in hopes of a better narrative)

https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...

A fine link, but oddly one that the two of us have already referenced in a different subthread. As stated there, I think there is room for a non-fwrapv approach that works just as well.

I try to use signed for all _numeric_ values (leaving unsigned for "bit strings"), because I'm quite sure that the number of bugs caused by the discontinuity at zero (for unsigned values) is much larger than the number caused by the discontinuity or UB at INT_MIN/INT_MAX.

I was probably unclear. I don't prefer unsigned to avoid the UB, but to get better generated assembly. While the unnecessary sign extension moves frequently come for free, occasionally they don't. I think the bugs are as likely to bite (or not bite) in either case, and need to be avoided by other means.

To see that with pretty much any program, just compare compiling with and without optimizations, or perhaps compare against a 20 or 30 year old C compiler if you can find one.

I'm less sure of that. You saw, for example, the current thread on RWT: https://www.realworldtech.com/forum/?threadid=182093&curpost...? I think the situation is rather that recent compilers do a better job with naive code, but are more likely to pessimize consciously constructed code. One major example of this is the most important micro-performance issue I've seen, which is the failure of GCC and Clang to reliably get µop macro-fusion bottom of loop branches. ICC does a much better job of keeping a decrement to zero tight to a fused jz, making the loop body one µop smaller.

These people are smart enough to get us into this situation, so one would imagine they'd be smart enough to least discuss this better way if it exists.

I lack that belief, but I'm not sure if that makes me more or less cynical than you. I think the issue is that almost everyone involved in standards process is likely to share a set of core philosophical beliefs about programming that may be self-consistent but not cover the full range of possibility. Consider as not quite parallels who becomes a US Supreme Court Justice or military commander, and how the selection process of being appointable affects the range of ideas espoused.

So what is this better way?

It might not be the solution, but I think that what you are not seeing is that there are other interpretations of "implementation defined" besides "always wrap" or saturate. You (and I think the standards committees) seem to want all non-UB programs to be fully deterministic, such that an emulator can always be written that will produce the same results as a real processor. I think there's room for an approach that says "if you stray beyond these rules, the real processor will decide your fate" without the "electric fence of death" approach currently taken by UB. I might be wrong to call this "implementation defined", but I think that's where it best fits in.

Consider a simple example: deallocating (e.g., free() in C, delete in C++) the same memory twice is UB, as is deallocating memory that was never allocated.

Let's use that an as example. What I want is for a standards compliant compiler to adopt this attitude: "It is unpredictable what happens if you call free twice in succession on the same pointer. Our compiler will try to issue a warning if it sees this happening, but the generated assembly is guaranteed to call free() twice. What happens after that is between you and your god."

I don't want is for it to be a guaranteed no-op. Nor do I want it the compiler to eliminate code based on the assumption that the second call never happens. I want it to warn if it can (which can be a fatal warning if desired) but to always generate assembly that makes the potentially crashing call. My contract with the compiler is limited to determinism of the assembly it generates on my behalf, and does not include any guarantees or restrictions on the runtime behavior.

My worry is that you (and others) don't consider this to be a standards compliant interpretation of "implementation defined", nor can it be "undefined behavior" if the compiler also reasons that UB can be assumed to never occur. Despite this, I think it would make the frequently make the compiler into a more useful tool.

> I think there's room for an approach that says "if you stray beyond these rules, the real processor will decide your fate" without the "electric fence of death" approach currently taken by UB. I might be wrong to call this "implementation defined", but I think that's where it best fits in.

How is this different from -fwrapv? The real processor implements the -fwrapv behavior, so it seems like the same thing.

If it's something different, how is it different than the current behavior of "compiler does whatever it wants and then the CPU executes the instructions"?

Maybe a specific example would help?

I think a key problem is that you are jumping ahead to "the real processor will decide your fate" - but that's not the interesting part. We all understand how real processors work (they wrap) - the whole question is what the language semantics of signed values are, because before you get to the processor, you have to compile the code. Even before that you have to write the code, and you want to know what happens when you do basic math on integers. If you want to invoke the specific processor behavior as part of the definition of how integers work, you also need to provide some kind of mapping from the source to machine operations (hint: I think -fwrapv behavior is the best or only way to do this practically).

> I don't want is for it to be a guaranteed no-op. Nor do I want it the compiler to eliminate code based on the assumption that the second call never happens. I want it to warn if it can (which can be a fatal warning if desired) but to always generate assembly that makes the potentially crashing call. My contract with the compiler is limited to determinism of the assembly it generates on my behalf, and does not include any guarantees or restrictions on the runtime behavior.

I see. What you basically want is a non-optimizing compiler, or a compiler that does only a limited amount of optimization following very strict rules (perhaps akin to something along the lines of how volatile is treated) about what can be optimized.

I think it is actually much more complicated than you would think (because the existing model of "as-if execution preserving required side-effects" is really very simple and clean).

More to the point, I don't think you'll ever get it [3] and you might not like what you get. 90% of optimization is eliminating code. The compiler eliminates function calls, assignments, math, allocations, jumps, branches, copies, constructors, and the list goes on forever. Elimination is the name of the game. Almost all of the time the result produced is indistinguishable from what you imagine the abstract machine doing, even though the combination of the compiler and real machine it is doing nothing like that at all.

These cases that get the press are notable for their exceptionality - at the intersection of a mismatch between what the standard says and how people imagine the language to work, and a similar mismatch between how people believe a compile (should?) work and how it does, and probably also a mismatch between the priorities of the compiler writers (performance on benchmarks) and users (correct code).

> My worry is that you (and others) don't consider this to be a standards compliant interpretation of "implementation defined", nor can it be "undefined behavior" if the compiler also reasons that UB can be assumed to never occur.

As above I'm not 100% clear on what you are suggesting, but I think it could be implementation defined as long as you can explain it (-fwrapv qualifies easily). After all, implementation defined has to be _defined_ in some way, right?

It could _definitely_ be UB, since UB can be whatever you want. A compiler could implement your suggestion right now and it would be within the rules. That just leaves us back where we are today though, right? Unknown or unexpected behavior in the presence of UB behavior.

I think there is a misconception that the "compiler assumes UB never occurs and removes all code that leads to UB". I think it's more accurate to say the compiler (in principle) just treats UB in the way that is most convenient (fast?) for the current context. In the specific case of a basic block that _always_ executes UB (e.g., references a pointer that is known to be not NULL), the most convenient/fast thing is probably to prune the code and paths that lead to this block - this type of thing happens all the time in non-buggy programs due to inlining, generic code, macros, auto-generated code, other optimization passes, etc.

In many other cases however, the most convenient thing to do is just to emit the instruction (or instruction sequence) that behaves in the required way for non-UB code, and behaves "as it will" on the hardware for UB code, like all the stuff around shifts, division by zero and even various builtins and intrinsics. The compiler doesn't go out of its way to remove the UB code, it just does what is fastest.

Nobody complains about the latter behavior though, but of course it leads to bugs all the same - but people blame the programmer, not the compiler in this case, because the result is more "obvious" (I think).

---

[3] The niche for a compiler that executes what you write more or less verbatim is just too small (beyond what you already get with -Og or -O0 or whatever): people write in C/C++ for speed, if you wanted something slower you have many better, safer options available.

> As stated there, I think there is room for a non-fwrapv approach that works just as well.

Maybe I am missing something, but I feel the compiler is doing exactly what you are suggesting in that subthread, and I replied in that vein. Perhaps I am misunderstanding what you are suggesting.

> I was probably unclear. I don't prefer unsigned to avoid the UB, but to get better generated assembly. While the unnecessary sign extension moves frequently come for free, occasionally they don't.

That seems backwards. Due to this "issue" the suggestion is that signed often generates better assembly, because the compiler can reason that overflow doesn't occur. With unsigned, the compiler must generate code that accommodates wraparound, since it is allowed to occur.

For example, I would have expected the example code in the link to compile to worse code if an unsigned loop counter is used, since wraparound is legal and so the compiler will have to zero-extend each value. As it turns out it doesn't, since of course the compiler can additionally prove that if wraparound occurs this particular loop won't even be entered (since the condition is `i < count`). This proof is quite fragile however, if the loop condition were different or if any other math occurs on index it would break as in [1].

So it is not the case that compiler exploitation of UB simply brings signed level with the performance of unsigned, but that it can make signed faster, and that's how it is usually presented/argued.

Now I'm certainly not saying it is always true that is signed is no slower than unsigned: signed has the advantage of no-wrapping semantics, while unsigned has the advantage of zero extension being free in some scenarios (on some platforms) since it can be rolled into some other operation which implicitly zero extends, which is what I think you were referring to [2]. Which one has an effect (or greater) effect depends on the code.

> I think the bugs are as likely to bite (or not bite) in either case, and need to be avoided by other means.

Definitely not. Code with unsigned is always just one subtraction away from a huge (nonsense) value. That issue is a real one that occurs all the time, and why even the C++ folks (who ISTM rarely admit errors) generally acknowledge that using unsigned for things like container sizes was an error (albeit an uncorrectable one).

Signed values on the other hand, only overflow if you actually have a gigantic value that exceeds 2^31 or 2^63 or whatever. In many cases such large values cannot occur due to range of possible values (i.e., the meaning of the values), and especially with 64-bit values are unlikely to occur outside of malice. Furthermore, unsigned values are still subject to this type of overflow - but at 2^32 (2^64) rather than 2^31 (2^63).

I agree though that you should still use other mechanisms to avoid overflow even with signed values, but there is benefit to defense in depth.

> I'm less sure of [compiler optimization having improved spectacularly]. You saw, for example, the current thread on RWT: https://www.realworldtech.com/forum/?threadid=182093&curpost...? I think the situation is rather that recent compilers do a better job with naive code, but are more likely to pessimize consciously constructed code.

I'm not saying compilers are infallible. I am definitely in the camp that compilers have a long way to go. I believe optimization has improved dramatically in the last few decades. Perhaps "spectacularly" was too strong. This RWT example doesn't seem to contradict this: this is code that should have been well-optimized even 20 years ago. It is not in the set of things that needed to get better, so it should stay about the same. Due to some flaws in gcc, it actually has gotten worse. It is is large, complex code with lots of abstractions where optimization has gotten better.

You could try -O1 vs -O2 also for a kind of litmus test of the power of optimization. It's not an exact analogy, but -O1 code isn't that far off what older compilers could do, as many of the expensive optimizations enabled by -O2 are also the more recent ones (not coincidentally, since increasing hardware speed has made these palatable). On some code it makes no difference, and you'll even find cases where -O1 is faster. On lots of code -O2 is faster, and in some cases dramatically so (10x, etc).

In fact, if you run this example on x86, you'll probably find a big difference between -O1, -O2 (on clang) and -O3 (on gcc).

In any case, I don't think we even need to agree on whether optimization has improved, and by how much? It's not really central to the discussion.

We just need to agree that optimization is an important part of C/C++ compilers, valued by many users and a key criteria of evaluation between compilers. I think that is not controversial?

> I lack that belief, but I'm not sure if that makes me more or less cynical than you.

Keep in mind these discussions involve not just compiler writers but any interested parties, including people who strongly object to the current behavior. So even if don't believe the compiler writers can see a solution due to some type of institutional myopia, where are all the clever suggestions from outsiders? How come every time this comes up the most popular opinion is some solution-free observation about how insane this is rather than "this is obviously how it should be done"? I put it to you that it is because there is no great solution waiting in the wings, and the three most sane solutions (UB, wrapping, trapping) are already implemented and selectable by the user.

> I think the issue is that almost everyone involved in standards process is likely to share a set of core philosophical beliefs about programming that may be self-consistent but not cover the full range of possibility.

I think the standards committee is only tangentially involved here. The primary way the standards committee is involved is that they defined signed overflow as UB, but that was almost certainly because _different machines implemented signed arithmetic differently_, not out of some desire for the occasional no-overflow optimization.

Years later the compiler writers "abused" this to implement this type of optimization. So it is more about the compiler writers, IMO and whether their choice(s) are sane (see above).

The standards committee may become involved again, primary because they may remove the compiler's license to optimize this as UB by defining the behavior, and I hope to see that in my lifetime.

> It might not be the solution, but I think that what you are not seeing is that there are other interpretations of "implementation defined" besides "always wrap" or saturate.

Yes, I am not seeing them, but I am open to them! In fact I am practically begging for someone to explain them to me (in a patient and precise way, not going silent when it becomes clear that the nugget of the idea they had actually doesn't survive when fleshed out).

Also, to be precise, I do see other ideas, like:

- Trapping on overflow. - Applying a heuristic to determine whether the user is actually anticipating overflow and allowing it to occur in that case, which would "fix" the overflow check case.

The first is already implemented and selectable, as far as I know, and the second seems likely to be worse than the other solutions, extremely controversial and very hard to implement.

> You (and I think the standards committees) seem to want all non-UB programs to be fully deterministic

On the part of the committee, I would say "definitely not", since otherwise they wouldn't have implementation defined behavior. From my part, I would say "Yes, that is obviously highly desirable!". I definitely want a deterministic, portable language. Anything else seems like a big mistake. Only C and C++ really deviate from this norm and mostly all in the name of performance. Weird behavior in the name of performance... somehow it seems like we are reversing our positions here?

One thing I'd like to see the standards committee do is have more implementation defined behavior, and feature-test macros to test it. The current implementation defined behavior is kind of useless to actually consume because you are supposed to hunt through the documentation for each compiler (if it even exists) and find what you want and hope it doesn't change in the future.

You could have fine-grained test macros, but it would even be great to have something like TWOS_COMPLEMENT_NOT_INSANE that means the platform has 8-bit bytes, two's complement signed and unsigned values, and everything behaves "as expected" in terms of conversions between them, etc.

Since pretty much every platform today has this, you could just have a:

    #if !TWOS_COMPLEMENT_NOT_INSANE
    #error "Sorry, this platform is to weird to support"
    #endif

in your project and then basically write in a narrowed version of C/C++ which meets many more expectations of how things should work.

---

[1] https://godbolt.org/z/BLsXJ5

[2] Other than this example, it is obvious that signed or unsigned can be slower than the other in cases where you are mixing and matching signedness within a loop in an inefficient way, especially when combined with mixing lengths (e.g., 32-bit vs 64-bit) as well.

Why do you assume we want either Pascal ("wrapping semantics") or random-"optimizations". Those are not the choices. It's actually very easy for the compiler to detect that it is a check to avoid overflow, it's the text of the program. You don't need to compile with wrapping semantics: the compiler generates code that actually does overflow the counter. All you need to do is to stop using invalid reasoning of the type: We assume that overflow cannot happen, yet generate code in which it does happen.

> Why do you assume we want either Pascal ("wrapping semantics") or random-"optimizations".

I don't think I assumed that.

I think there are a variety of ways of dealing with the overflow issue, which fall at a variety of points within the multi-dimensional design space that includes considerations like (a) comprehensibility by the average programmer and principle of least surprise (b) performance (c) fast failure (d) portability across hardware.

I don't know if C and C++ made the right decision with leaving this UB, nor am I convinced of the compiler writers method of handling the UB, but they are at least consistent in usually favoring performance and portability above other concerns. That it, is it is not obviously wrong to me or, nor dominated with another obviously better behavior.

> It's actually very easy for the compiler to detect that it is a check to avoid overflow, it's the text of the program.

I guess you are suggesting some type of idiom recognition, which will preserve these checks, but still allow full optimization in other cases where overflow is not expected or the intent of the programmer was different? I don't think that will ever happen. The best you can hope for is that the involved compilers simply decide to define signed overflow as wrapping, i.e., make the -fwrapv behavior the default. Personally I think that's a reasonable choice.

I can't imagine it is ever the intent of the programmer that if(i+1 < i)x be there simply as decoration to be removed by the compiler. If the compiler can deduce that the test will evaluate as false (or true), it is perfectly reasonable to optimize by deleting the line (or the check, in case of true). But this should be sound deduction. For example, if the target processor traps on overflow, the compiler can deduct that the conditional is always false. But what GCC/Clang do now is (a) generate machine code on x86 and ARM that does wrap, and (b) transform code on the axiom that ints will not wrap!That is, they take "false" for a theorem.

> I can't imagine it is ever the intent of the programmer that if(i+1 < i)x be there simply as decoration to be removed by the compiler.

I agree.

> But this should be sound deduction. For example, if the target processor traps on overflow, the compiler can deduct that the conditional is always false. But what GCC/Clang do now is (a) generate machine code on x86 and ARM that does wrap, and (b) transform code on the axiom that ints will not wrap!That is, they take "false" for a theorem.

I understand the desire, but you are talking about a different language, maybe assembly. C and C++ compilers just aren't in the habit of purposely compiling ill-formed code differently depending on the target processor. First and foremost they apply the rules of the language, and the rules are oriented towards portable-yet-fast code, and then as a last step they generate assembly or machine code.

I _really_ don't think you want the compiler changing the rules of the game depending on the target architecture. In fact, the trend is almost entirely away from this in all modern languages: towards a single consistent execution regardless of the architecture.

So the "deductions" you talk about are necessarily going to be against the abstract machine defined in the language, not against the final target.

It worth noting too that there is even an increasing trend towards separating the higher-level compilation and optimization and the final generation of a binary from the IR, for example in the Apple App Store I think you now submit IR which can be specialized by the store itself for each target device, including some not created yet. So at least in the initial stages of compilation, you may not even know the target, or it may not even exist at the current time!

Even the C standard still pays lip service to the notion of C as high level assembler. The notion that C should be an abstract high level language insulated from the machine is foreign both to the language design and usage. C is not designed to be memory safe, for example. The intent of implementation dependent and undefined in the C specification was to make explicit that the compiler was not entrusted with safeguarding the programmer against non-portable use. The bizarre theory that this can be interpreted as a license to sabotage the programmer in the case of non-portable use makes C unusable for its intended purposes - even if it make it possible to wring performance from terribly written benchmarks.

Reply on news.ycombinator.com