2 ms·
https://reviews.llvm.org/D54604 https://reviews.llvm.org/D54604 https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fwrapv https://clang
by GoblinSlayer 5y ago
https://reviews.llvm.org/D54604 https://reviews.llvm.org/D54604
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fwrapv https://clang.llvm.org/docs/ClangCommandLineReference.html#c...
- Joky 5y agoBut these are options, it's not a big deal to me that compiler offers special options for special use cases. It's not clear to me if you are saying that the *default* for clang and GCC differs, aren't they both using `fno-wrapv` by default?
- GoblinSlayer 5y agoThese options provide a different interpretation of UB like signed integer overflow and implicit initialization. It's in reference to Ralf's blog post: >I honestly think trying to write a highly optimizing compiler based on a different interpretation of UB would be a worthwhile experiment. We sorely lack data on how big the performance gain of exploiting UB actually is. However, I strongly doubt that the result would even come close to the most widely used compilers today—and programmers that can accept such a big performance hit would probably not use C to begin with. Certainly, any proposal for requiring compilers to curtail their exploitation of UB must come with evidence that this would even be possible while keeping C a viable language for performance-sensitive code. He doesn't know such interpretations are implemented by widely used C compilers.