[llvm-commits] [compiler-rt] r166660 - in /compiler-rt/trunk/lib/ubsan: CMakeLists.txt lit_tests/TypeCheck/vptr.cpp ubsan_handlers.cc ubsan_handlers_cxx.cc ubsan_handlers_cxx.h ubsan_type_hash.cc ubsan_type_hash.h

[Richard Smith]

On Thu, Oct 25, 2012 at 11:03 AM, Sean Silva <silvas at purdue.edu> wrote:
> +  // lib/VMCore/Instructions.cpp:2020:10: fatal error: member call on address
> +  //       0xb7a4440 which does not point to an object of type
> +  //       'llvm::OverflowingBinaryOperator'
> +  //   return cast<OverflowingBinaryOperator>(this)->hasNoSignedWrap();
> +  //                                               ^
> +  // 0xb7a4440: note: object is of type 'llvm::BinaryOperator'
> +  //   00 00 00 00  e0 f7 c5 09 00 00 00 00  20 00 00 00
> +  //                ^~~~~~~~~~~
> +  //                vptr for 'llvm::BinaryOperator'
>
> How could this ever happen? Operator's are never instantiated.

BinaryOperator is an Instruction, not an Operator. :-)

> The vptr would have to be that of one of the Instruction or
> ConstantExpr subclasses. For this particular situation with Operator,
> you can just delete all of the rogue classof()'s in
> include/llvm/Operator.h that take Instruction* or ConstantExpr*, and
> then all of these invalid casts will get flagged by the compiler.

Sure, the tool has less value in cases where you already know that
you're breaking the rules all over the place.