[LLVMdev] Incorrect loop optimization when building the Linux kernel

[David Majnemer]

Nick, consider:

char a[0];
char b[0];

at run-time:
(gdb) p &a
$1 = (char (*)[]) 0x60103c
(gdb) p &b
$2 = (char (*)[]) 0x60103c

Even if this is not safe at the C or C++ level, this comparison could
return equal or not equal depending on what the linker chooses to do.

Do we have a bug in the constant folder?


On Sun, Dec 7, 2014 at 11:16 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Chengyu Song wrote:
>
>> It's difficult to say without a full example, but I'm very suspicious
>>> of those global declarations. I think the compiler would be entirely
>>> justified in assuming you could *never* get from __start_builtin_fw to
>>> __end_builtin_fw, let alone on the first iteration: they're distinct
>>> array objects and by definition (within C99) can't overlap.
>>>
>>
>> I think this should be the root cause. Once I changed the declaration to
>> pointers (instead of arrays):
>>
>> extern struct builtin_fw* __start_builtin_fw;
>> extern struct builtin_fw* __end_builtin_fw;
>>
>> The generated code will not skip the first comparison.
>>
>> Sadly, Linux kernel may contain more such declarations.
>>
>
> That's a great point. Maybe clang could issue a warning on these, any for
> loop that declares a pointer to the address of a non-weak object, compares
> it to a different object, and increments only the pointer (without doing
> other changes to the pointer inside the loop body). We know that's a buggy
> pattern. Could you file a feature request for this on llvm.org/bugs ?
>
> Nick
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141208/e264a3c0/attachment.html>