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

[Dmitry Babokin via cfe-dev]

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/20161213/93741684/attachment.html>