[PATCH] Annotate our UB to sneak it past the sanitizers

Justin Bogner via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 26 15:24:55 PST 2016

David Blaikie <dblaikie at gmail.com> writes:
> On Fri, Feb 26, 2016 at 2:56 PM, Justin Bogner via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>> Alexey Samsonov <vonosmas at gmail.com> writes:
>> > What are the failures you observe? We're running an UBSan bootstrap on
>> our
>> > buildbot, and it's usually green:
>> >
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11059
>> Is that running without any blacklists? These are both the undefined
>> behaviour in ilist_node and how we use it, ie:
>>   runtime error: downcast of address XXX with insufficient space for an
>> object of type 'llvm::MachineBasicBlock'
>> This is because "Sentinel" in both of these functions is an
>> ilist_half_node, which is certainly not large enough.
>> It's certainly been necessary to blacklist MachineFunction on darwin
>> since at least October, though the bug existed and wasn't caught by
>> ubsan before that:
>>   http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
>> The one in MemorySSA just started hitting a month or so ago.
> MemorySSA was only added a month or so ago, wasn't it? If it was added with
> UB in it, it should probably have been removed/fixed, no?

Well, maybe, but it used an idiom that's used in 8 other places in
LLVM (and is UB every time). It's not really MemorySSA that's at fault
here, but iplist.

I don't know why ubsan doesn't seem to detect the other instances of
this UB in the ilist_traits for SparseBitVectorElement, IVStrideUse,
MachineInstr, SDNode, IndexListEntry, NAmedMDNode, and
SymbolRewriter::RewriteDescriptor. Presumably it could start.

Should I annotate them too?

More information about the llvm-commits mailing list