> On Jan 8, 2021, at 17:50, Paul C. Anagnostopoulos via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>
> I'm sorry, I still don't understand. I've never seen this sort
of error before. Why is the assert.td test failing in this build when it
doesn't fail on my machine? Different compiled code, possibly?
>
> Can I trust this message?
>
Yes, you should be able to trust this message.
The bot builds LLVM with the undefined behavior sanitizer, which will insert
runtime checks to catch cases of undefined behavior in the source. You need a
version of LLVM that is build with the UBsan enabled to reproduce it.
> TGParser.cpp:3213:22: runtime error: reference binding to null pointer of
type 'llvm::Record'
>
Looks like the code on that line is
https://github.com/llvm/llvm-project/blob/6e2b6351d2cb1feaa88e6c92ba844ab48b4758f9/llvm/lib/TableGen/TGParser.cpp#L3213
RecordResolver R(*CurRec);
CurRec is a pointer of type llvm::Record. The message ("runtime error:
reference binding to null pointer of type 'llvm::Record’) is indicating that
a null pointer is de-referenced (so it can be bound to a reference, likely
RecordResolver’s constructor takes an argument `Record &`).
So there is a code path executed where CurRec is a nullptr.
> There is nothing in line 3213 that deals with the Record type.
>
> If I try to build with the Undefined sanitizer with Visual Studio, I get:
> CMake Error at cmake/modules/HandleLLVMOptions.cmake:801 (message):
> This sanitizer not yet supported in the MSVC environment: Undefined
>
Looks like this is not supported with MSVC then unfortunately. The good news is
if it is indeed a nullptr dereference, you can just add an assertion that
`CurRec` is not nullptr to track down the issue.
Cheers,
Florian