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.