Most sanitizer built-in argument types are all of pointer types. For example:
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS as BT_FN_VOID_PTR_PTR_PTR or BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE as BT_FN_VOID_PTR_PTR. But some calls to these functions are made with some arguments of integer types. For instance, the sanitized code for the shift expression below: int f (int i, int j) { return i << j; } is this: <bb 3> : _9 = (unsigned long) j.0_13; _10 = (unsigned long) i.1_15; # .MEM_17 = VDEF <.MEM_16(D)> __builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, _10, _9); As a result, gimple_call_builtin_p() returns false for such calls because the arguments don't match the expected types. Assuming the function types are that way on purpose, is it expected that gimple_call_builtin_p() fail for these calls? If so, what's the recommended way to test a statement to see if it's a sanitizer built-in? ASAN uses gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) to see if a statement is the result of instrumentation (in has_stmt_been_instrumented_p) and this test fails for the same reason. I don't know if it matters, I was just looking for a way to check that succeeds even for these calls. Thanks Martin