Comment by nickelpro

Comment by nickelpro a day ago

4 replies

People keep saying "O3 has bugs," but that's not true. At least no more bugs than O2. It did and does more aggressively expose UB code, but that isn't why people avoid O3.

You generally avoid O3 because it's slower. Slower to compile, and slower to run. Aggressively unrolling loops and larger inlining windows bloat code size to the degree it impacts icache.

The optimization levels aren't "how fast do you want to code to go", they're "how aggressive do you want the optimizer to be." The most aggressive optimizations are largely unproven and left in O3 until they are generally useful, at which point they move to O2.

uecker 20 hours ago

I would say there is a fair share of cases where programmers were told it is UB when it actually was a compiler bug - or non-conformance.

  • saagarjha 10 hours ago

    That share is a vanishingly small fraction of cases.

    • uecker 6 hours ago

      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.

SubjectToChange 21 hours ago

More aggressive optimization is necessarily going to be more error prone. In particular, the fact that -O3 is "the path less traveled" means that a higher number of latent bugs exist. That said, if code breaks under -O3, then either it needs to be fixed or a bug report needs to be filed.