David Majnemer
2014-Dec-08 10:03 UTC
[LLVMdev] Incorrect loop optimization when building the Linux kernel
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>
Joerg Sonnenberger
2014-Dec-08 17:06 UTC
[LLVMdev] Incorrect loop optimization when building the Linux kernel
On Mon, Dec 08, 2014 at 02:03:28AM -0800, David Majnemer wrote:> 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.It is invalid C as is the original code. If you want to play such linker games, mark one of the objects involved as weak. Joerg
David Majnemer
2014-Dec-08 17:58 UTC
[LLVMdev] Incorrect loop optimization when building the Linux kernel
On Monday, December 8, 2014, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> On Mon, Dec 08, 2014 at 02:03:28AM -0800, David Majnemer wrote: > > 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. > > It is invalid C as is the original code. If you want to play such linker > games, mark one of the objects involved as weak.Right, but nothing forbids this comparison at the IR level.> > Joerg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <javascript:;> 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/8d2186f0/attachment.html>