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
