vsk added a comment. In https://reviews.llvm.org/D30423#694003, @jroelofs wrote:
> I think this might miss loads from bitfield ivars. I'll add a test that shows that this case is covered. > Also, what about the conversion that happens for properties whose backing > ivar is a bitfield? (or does that happen in the runtime? can't remember) I'll also check that synthesized getters have the range check. ================ Comment at: test/CodeGenObjC/ubsan-bool.m:26 + // OBJC: [[ICMP:%.*]] = icmp ule i8 [[ASHR]], 1, !nosanitize + // OBJC: call void @__ubsan_handle_load_invalid_value + ---------------- jroelofs wrote: > vsk wrote: > > arphaman wrote: > > > Is it possible to avoid the check here since the bitfield is just one bit > > > wide? > > No, a user could do: > > > > ``` > > struct S1 s; > > s.b1 = 1; > > if (s.b1 == 1) // evaluates to false, s.b1 is negative > > ``` > > > > With this patch we get: > > ``` > > runtime error: load of value -1, which is not a valid value for type 'BOOL' > > (aka 'signed char') > > ``` > What if BOOL is an `unsigned char`, or a `char` that's not signed? Good point, we don't need to emit the range check if the bitfield is an unsigned, 1-bit wide BOOL. Would you be OK with me tackling that in a follow-up patch? https://reviews.llvm.org/D30423 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
