<div dir="ltr">LGTM. I'd probably keep the amount of annotations to a minimum for now.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 5:09 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> writes:<br>
> On Fri, Feb 26, 2016 at 2:56 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
>> Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> writes:<br>
>>> What are the failures you observe? We're running an UBSan bootstrap on our<br>
>>> buildbot, and it's usually green:<br>
>>><br>
>> <a href="http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11059" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11059</a><br>
>><br>
>> Is that running without any blacklists?<br>
><br>
> Hm, not really. cmake -DLLVM_USE_SANITIZER=Undefined expands to<br>
> "-fsanitize=undefined -fno-sanitize=vptr,function",<br>
> but this specific error seem to be coming from -fsanitize=object-size.<br>
><br>
>> These are both the undefined<br>
>> behaviour in ilist_node and how we use it, ie:<br>
>><br>
>>   runtime error: downcast of address XXX with insufficient space for an object of type 'llvm::MachineBasicBlock'<br>
>><br>
>> This is because "Sentinel" in both of these functions is an<br>
>> ilist_half_node, which is certainly not large enough.<br>
>><br>
>> It's certainly been necessary to blacklist MachineFunction on darwin<br>
>> since at least October, though the bug existed and wasn't caught by<br>
>> ubsan before that:<br>
>><br>
>>   <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html</a><br>
>><br>
>> The one in MemorySSA just started hitting a month or so ago.<br>
>><br>
>>> On Thu, Feb 25, 2016 at 2:42 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>>>> Sounds very scary.<br>
>>>> At the very least we should specify which flavor of UB we allow<br>
>>>> here (not just all of it)<br>
>><br>
>> The macro expands to no_sanitize("undefined") right now - does<br>
>> no_sanitize take a more specific argument?<br>
>><br>
>>> +1 I would prefer LLVM_NO_SANITIZE("kind") macro.<br>
>><br>
>> Sure. I'll update the patch.<br>
><br>
> Yes, you can use smth. like<br>
>   __attribute__((no_sanitize("signed-integer-overflow")))<br>
<br>
</div></div>Here's an updated patch. This ones refers to the PR, renames the macro<br>
LLVM_NO_SANITIZE() and calls it with "object-size" instead of<br>
"undefined".<br>
<br>
Optionally, I could annotate the 7 other cases of this UB that aren't<br>
currently caught by running check-all under ubsan. I'm not sure which<br>
way's better - thoughts?<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div>