Optimisations and undefined behaviour

[Jeff Law]

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.



jeff