[cfe-dev] ubsan: problem with detecting UB in shift operation with large RHS

[Dmitry Babokin via cfe-dev]

Could someone have a look at this bug, please?

https://llvm.org/bugs/show_bug.cgi?id=27271

On Tue, Dec 13, 2016 at 4:08 PM, Dmitry Babokin <babokin at gmail.com> wrote:

> Before filing the bug I've looked for existing bug reports and found one
> for exactly this problem: 27271.
>
> On Tue, Dec 13, 2016 at 3:35 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On 12 December 2016 at 14:46, Dmitry Babokin via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Hello,
>>>
>>> I'm using ubsan together with creduce to ensure that reduced test
>>> doesn't have UB. And I've noticed that ubsan is not detecting UB in case of
>>> large shift amount, particularly when rhs of shift has larger type that
>>> lhs. To reproduce, rhs also has to have the value that is non-zero, but
>>> after truncation to lhs type the value becomes zero.
>>>
>>> Consider the following example.
>>>
>>> #include <stdio.h>
>>>
>>> // 1 is in 33rd bit.
>>> unsigned long long l = 0x100000000ULL;
>>>
>>> int main() {
>>>     // Ubsan doesn't fire
>>>     int res = 123 >> 0x100000000ULL;
>>>     // Ubsan doesn't fire
>>>     res += 123 >> l;
>>>     // Ubsan does fire
>>>     res += 123ULL >> l;
>>>     printf("result = %d\n", res);
>>>     return 0;
>>> }
>>>
>>> Changing the constant to the value, which fit 32 bits makes ubsan firing.
>>>
>>> I understand where the problem comes from - LLVM IR definition requires
>>> both operands of the shift to be of the same integer type. And ubsan
>>> actually check already truncated value. But it doesn't match C/C++ standard
>>> definition of UB in shift operation.
>>>
>>> Is it possible to fix in current infrastructure? Should I file a bug for
>>> this problem?
>>>
>>
>> Yes and yes. I would expect that we just need to reorder the check to
>> before we truncate the RHS.
>>
>>
>>> Note, it's not a theoretical problem, it's very practical one, which
>>> pops up during automatic test reduction relatively frequently for me.
>>>
>>> Dmitry.
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170108/f1b664e9/attachment.html>