search for: chengyu

I'm not sure, I was never able to compile the whole kernel with -O0, too many errors. Plus, the problem seems to be within machine code generation. I tried opt -O1 and -O2, the generated .ll file does not diff much for the target function (insert_leaf_info). Thanks, Chengyu > On Dec 9, 2014, at 4:49 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014 at 13:46, Chengyu Song <csong84 at gatech.edu> wrote: >> Then I will attach, and it is compiled with -O0 > > I thought you said the problem occurred at O1 and O...

Should I just copy and paste the content of the .ll file? Thanks, Chengyu > On Dec 9, 2014, at 4:35 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >>> Thanks for the IR snippet (I agree, it does look like the order is >>> reasonable there), but it's not really enough to debug the problem. We >>> need an actual Module...

...8] It should be: f94006a8 ldr x8, [x21,#8] f9000668 str x8, [x19,#8] f9000275 str x21, [x19] d5033abf dmb ishst f9400669 ldr x9, [x19,#8] f9000133 str x19, [x9] f90006b3 str x19, [x21,#8] I guess it’s because "dmb ishst" is not checked/tested? Any quick way to fix this? Thanks, Chengyu

I'm using r223407. Switching to a clean built on r223853, it still gives me: ldr x8, [x21,#8] stp x21, x8, [x19] dmb ishst ldr x8, [x19,#8] str x19, [x8] str x19, [x21,#8] Thanks, Chengyu > On Dec 9, 2014, at 6:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu> wrote: >> Errr. my fault. I patched the rcu_assign_pointer ... Let me try again. > > It's looking closer now,...

...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. Thanks a lot! Chengyu

...; preds = %13 br label %.loopexit .loopexit: ; preds = %.loopexit.loopexit, %6 %.0 = phi i1 [ true, %6 ], [ false, %.loopexit.loopexit ] ret i1 %.0, !dbg !4004 } Could anyone explain why this is unhappening and how to avoid it. Thanks, Chengyu

...he IR snippet (I agree, it does look like the order is > reasonable there), but it's not really enough to debug the problem. We > need an actual Module we can compile and examine to have a hope of > finding out what's going on. You mean the source code I'm compiling? Thanks, Chengyu

On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer wrote: > I'm pretty sure this is fixed in r223684. This particular use of > zero-sized arrays should defeat any chance of compile-time address equality. I object that change. It's a horrible special case hack for either a fundamental issue in the IR or plain UB on the source level. As such, it should be reverted. Joerg

...#5, !dbg !10252, !srcloc !10255 %43 = load %struct.hlist_node*** %41, align 8, !dbg !10252 store %struct.hlist_node* %37, %struct.hlist_node** %43, align 8, !dbg !10252 store %struct.hlist_node** %42, %struct.hlist_node*** %39, align 8, !dbg !10256 br label %hlist_add_head_rcu.exit Thanks, Chengyu

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...

..."x19 + 8" is written before it gets read. Indeed. I didn't pay too much attention to the str -> stp change. Unfortunately, the trunk build crashes when compiling the kernel. Hope it will be fixed tomorrow, else I need to find a revision that gives me this fix. Thank you so much! Chengyu

...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...