-O3 is for optimizations that are mostly not risky.
-O2 is for optimizations that don't involve a speed/size tradeoff
-O1 is for optimizations that don't slow your compiler down too much
Obviously these are fuzzy categories, but -O4 is where "undefined behavior" optimizations belong. Alternately, each individual optimization has its own flag, and can be turned on individually.
Currently, there are no optimizations that fit in that category, but as recently as 2003 I remember seeing it in the man pages. I believe there was -O5 and -O6 too, but I don't trust my memory enough to be certain.
Maybe I remembered the history wrong. There are definitely cases of people using -O4 http://www.larcenists.org/Twobit/KVW/kvwbenchmarks.html .
There are definitely optimization options which are (or have been) available that are not turned on by -O3. For example:
-ffast-math
-funroll-all-loops
-fstrict-aliasing
Are not turned on (for good reasons: unrolling loops often slows a program down).
So there's no reason UB optimizations need to be turned on by default, or with -O3. You could throw them in -Ofast or use -Oub, or use optimization specific flags (they should have optimization specific flags in any case) and that was my main point.
That is a very different thing that turning on optimizations that might break non-standard-conforming programs!
I think the idea of making it controlled by optimization flags is interesting, but you would need to formalize what the more "safe" variant of the language is if people are actually going to depend on it.
You're talking as though the standard were well-defined. It's not.