https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #18 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote: > In the testcase, there is nothing that violates ABI. It all happens in "g" > that > passes calculated result to a function. Selected function depends on flags, > calculated from the subtraction, and wrong function gets selected when > overflow > happens. Thanks for the explanation. As long as the transformation is local (relying on an OF value that definitely comes from a particular instruction that would clear it in the absence of overflow, not relying on other computations not having overflowed), using it should be valid, provided you take into account that RTL has no undefined behavior on signed overflow (flag_wrapv only affects GIMPLE semantics, not RTL semantics), so the flag can only be used when instruction semantics for when it is set are consistent with the RTL semantics for the comparison. What's not valid is using sticky overflow flags such as exist in some instruction sets.
