[lyricaljoke]

I think your complaint is reasonable, but I also can see their logic in making what's considered UB consistent for -O0 and other optimization levels. The reason is that for most use cases, I think it's pretty typical to develop and debug with -O0 and compile for release with stronger optimizations and other options basically unchanged. There's an argument that in this case, making UB consistent for -O0 might expose code that relies on UB earlier in the process, whereas before it may have been found much later (or never!).

I understand that there are some use cases where teams release binaries compiled with -O0 if they've identified that avoiding unexpected effects of aggressive optimization is more important than raw performance. But in this case, it seems like the right solution is to allow such teams to specifically opt in to allowing overflow via -fwrapv.

[dooglius]

> for most use cases, I think it's pretty typical to develop and debug with -O0 and compile for release with stronger optimizations and other options basically unchanged

Be that as it may in most cases, the compiler shouldn't make an assumption that this is always the case. If I don't pass any optimization options, and especially if I pass -O0, the correct behavior should be "no surprises".

If we do want to redefine -O0 as "dev/debug build for code that will eventually be built with optimizations" rather than just "no funny stuff with my code", there are still a couple problems with that. For one thing, a flag intended for debugging with some optimizations already exists, -Og. Also, if the goal is to expose UB sooner, why not just enable UBsan for these builds?

> I understand that there are some use cases where teams release binaries compiled with -O0 if they've identified that avoiding unexpected effects of aggressive optimization is more important than raw performance. But in this case, it seems like the right solution is to allow such teams to specifically opt in to allowing overflow via -fwrapv.

I think you're underestimating the amount of people who will run "cc foo.c -o foo" and expect it to work, without thinking too much about UB as defined in the C standard, and who haven't ever heard of -fwrapv. By virtue of passing "-O1" in, it's safe for the compiler to assume you know what you're doing, but the default behavior should treat the user as a novice.

[lyricaljoke]

> Be that as it may in most cases, the compiler shouldn't make an assumption that this is always the case. If I don't pass any optimization options, and especially if I pass -O0, the correct behavior should be "no surprises".

The problem with this argument is that before the compiler even enters the picture, the C standard has always specified that signed overflow is UB. I'd argue that providing the additional guarantee that "actually, it'd defined" for the -O0 case only is a bigger surprise than "funny stuff with your code." To categorize treating signed overflow as UB as doing "funny stuff" is off the mark; the behavior was always unspecified.

> I think you're underestimating the amount of people who will run "cc foo.c -o foo" and expect it to work, without thinking too much about UB as defined in the C standard, and who haven't ever heard of -fwrapv. By virtue of passing "-O1" in, it's safe for the compiler to assume you know what you're doing, but the default behavior should treat the user as a novice.

I can't remember the last time I actually invoked a C compiler directly on the command line in the way you're describing (rather than through higher-level build configuration; e.g. generated Makefiles, VS solutions, whatever). I would hope such a use case for non-toy code is... rare.

[wilun]

You can not expect any consistency with UB.

[lyricaljoke]

I don't disagree, and I'm not sure what about my comment would suggest that I expect consistency there. What I was arguing was that any code relying on UB is dangerous / broken, so it's a good idea to surface any underlying code issues at all optimization levels by standardizing how it's handled.

[pritambaral]

Yes, but a more-consistent-with-UB compiler is better to use than a less-consistent-with-UB.

[amadvance]

For avoiding unexpected effects on legacy code, I use: -fno-strict-aliasing -fno-strict-overflow (like -fwrapv but valid also on old gcc) -fsigned-char (for building on ARM)