[cfe-dev] -fcatch-undefined-behavior testing

[Mike Stump]

On Dec 16, 2009, at 3:47 AM, Török Edwin wrote:
> This is a very interesting feature!

> However I found no way to skip this error, to look for more errors.

Yeah, limitation of the current codegen.  Trivially, one could imagine logging interface codegen.  It could include column and line numbers, filenames and what rule was violated and how (the shift amount was 128 bits).  I think filing a PR for a logging system would make a nice addition.  Great for large codebases when build test cycle times are in the 1-3 day range.

> Also would it be possible to warn about shift exceeding width only if they can change the outcome?

Well, the notion that some undefined behavior is defined and perfectly ok, is an odd notion.  Rather, think of it this way, the runtime check is trying to tell you that the `portable' version of ROR doesn't work on ppc and that you need to fix your code to be portable.  After it is fixed, there will be no runtime failure.  In fact, one of the purposes of the check was to find exactly this type of non-portable code.

> The shift of 32 could be worked around by checking whether b is 0, but that adds another branch.

A branch on a constant is relatively free.  A smart optimizer, having a ror instruction on the target, would always eliminate the branch as well.

Consider what happens when a is constant, and the emulation for shift at compile time doesn't match the runtime behavior of shift, the wrong value is computed.  Might not happen on a native compiler, but odds of this happening under cross compilation go up.