This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/09/2015 03:21 PM, Vincent Lefevre wrote:
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.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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |