Optimisations and undefined behaviour
Mon Nov 9 22:29:00 GMT 2015
On 11/09/2015 03:21 PM, Vincent Lefevre wrote:
> On 2015-11-09 15:11:27 -0700, Jeff Law wrote:
>> I feel it's best to err on the side of safety here -- given a function call,
>> loops and the like, we have to consider the possibility that the statement
>> which exhibits UB may not be executed. And until that statement is
>> executed, we have no license to do anything weird.
> BTW, the C standard says that a function may be interrupted by a
> signal at any time. So, if some code that has a visible side effect
> appears before an UB, the program may be interrupted between this
> code and the UB so that the UB will not occur. Thus a compiler does
> not have the license to remove such code with side effect.
Yup. And again, with the way the path isolation code works it'll be
handled correctly :-) We duplicate the path up to and including the UB
statement, then transform the statement which triggers UB in that
duplicated path into a trap.
The main benefit is not in optimizing the UB path itself, but in
removing the CFG edge from the point after the statement with UB back to
the main (non-UB) control flow path. It'd be nice to remove the path
leading *to* the UB statement, but that's not correct to do.
More information about the Gcc-help