[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

[Sean Silva]

>> How could this ever happen? Operator's are never instantiated.
>
> BinaryOperator is an Instruction, not an Operator. :-)

D'oh!

-- Sean Silva

On Thu, Oct 25, 2012 at 4:54 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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.