Re:Three proposals for the C standard WG14
by keldaris on Friday June 22, 2018 @03:23AM
(#17372100)
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.
[ Parent
| on HN ]
Re:Three proposals for the C standard WG14
by vyodaiken on Friday June 22, 2018 @10:29AM
(#17374192)
One 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.
Re:Three proposals for the C standard WG14
by keldaris on Saturday June 23, 2018 @09:32AM
(#17381180)
Which 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.
Re:Three proposals for the C standard WG14
by vyodaiken on Saturday June 23, 2018 @11:30AM
(#17381704)
I 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?