That share is a vanishingly small fraction of cases.

I am not sure. I saw quite a few of these bugs where programmers were told it is UB but it isn't.

For example, people showed me

  extern void g(int x);

  int f(int a, int b)
  {
    g(b ? 42 : 43);
    return a / b;
  }

as an example on how compilers exploit "time-travelling" UB to optimize code, but it is just a compiler bug that got fixed once I reported it:

https://developercommunity.visualstudio.com/t/Invalid-optimi...

Other compilers have similar issues.

You're an expert, you're overestimating the competence of the median programmer.

That's a great bug you found, and of course it is a compiler bug, not UB.

99.9% of the bugs I've dealt with of this sort were just pointer aliasing. Or just use-after-free. Or just buffer overruns.

The median programmer, especially in the good ol' days, wrote UB code about once every 6-10 hours.

Sure. All I am saying is that there are still plenty of compiler bugs related to optimization, which is reason enough for me to recommend being careful with optimization in contexts where correctness is important.

I agree that compilers have issues and that you have clearly run into some of them. I disagree with whether they are are more common than writing UB.

Oh, I didn't meant to imply that there are more common, just that they are common enough to be careful with optimizations.

Sure, I guess? In my experience I turn on the optimizer mostly without fear because I know that if, in the rare case I need to track down an optimizer bug, it would look the same as my process for identifying any other sort of crazy bug and in this case it will at least have a straightforward resolution.