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

[Török Edwin]

On 2009-12-16 05:26, Mike Stump wrote:
> If people want to try a neat new feature, go ahead and compile your software with -fcatch-undefined-behavior and then test your software.  If there are any traps at runtime, investigate your code and see if it is trying to execute some undefined behavior.  See http://clang.llvm.org/docs/UsersManual.html#codegen for some details on the checks that are inserted.
>
> Questions, comments, concerns...  let me know.  If it catches any real bugs, that'd be interesting to know.  If you find any bugs, I'd be interested in those as well.

Hi,

This is a very interesting feature!

I tested it (after reverting r91380 locally) on ClamAV.
It found a shift > bitwidth error, and got a SIGILL. So far so good.

However I found no way to skip this error, to look for more errors.
Would it be possible to emit something else instead of __builtin_trap()?
Perhaps a debugger breakpoint, or something else that can be skipped.

Also would it be possible to warn about shift exceeding width only if
they can change the outcome?
Consider this code from ClamAV, which for b == 0 does a left shift by 32
on a 32-bit var:
#define CLI_ROR(a,b) a = (( a >> (b % (sizeof(a)<<3) ))  |  (a << ( 
(sizeof(a)<<3)  -  (b % (sizeof(a)<<3 )) ) ))

If the shift of 32 is implemented as shifting out all the bits, then the
result is a|0 -> a.
If the shift of 32 is implemented as a shift considering the low bits
only, then its a shift by 0, and the result is a|a -> a.
So regardless how the shift of 32 is implemented the outcome is a, right?
The intent of the macro is to emulate the x86 ror instruction, and both
llvm/gcc know to turn it into a ror when compiled
if b is constant. However neither knows to turn it into a ror if b is
not a constant...
The shift of 32 could be worked around by checking whether b is 0, but
that adds another branch.

Best regards,
--Edwin