3 ms·
Well, now I'm confused. When does the compiler defeat programmer intentions? If you specify -fwrapv and insert manual overflow checks wherever you wish, the com
by keldaris 8y ago
Well, now I'm confused. When does the compiler defeat programmer intentions? If you specify -fwrapv and insert manual overflow checks wherever you wish, the compiler will never optimize them away and you will have as many runtime checks as you want. Programmer control is not compromised, which is good.
- vyodaiken 8y agoOne of the motivating cases for this proposal is that gcc/clang, without fwrapv, will both implement wrapping on most architectures (since that is what the processor implemements) and silently remove manual overflow checks for overflow because it is "impossible" under a stupid interpretation of what UB means. Similarly, those compilers will remove manual checks for null pointers if there is a prior dereference to a pointer on the theory that dereferences of null pointers are "impossible" even when they happen.
- keldaris 8y agoWhich is a very reasonable assumption for an optimizer. Every major compiler has switches to turn that behavior off. I'd be sympathetic to an argument that perhaps those switches should be on by default, but if you change the language standard, you're essentially saying entire classes of optimizations should be outright prohibited by a conformant compiler, with no programmer control. That's a classic case of throwing out the baby with the bathwater.
- vyodaiken 8y agoI do not see how FALSE is ever a reasonable assumption for an optimizer: " a+1 > a" is not a true statement for code emitted by gcc/clang on most architectures (with or without frwapv) Can you put one of your fwrapv deoptimizations on godbolt or otherwise show it?