[LLVMdev] how to track down a kernel miscompilation?

[John Regehr]

Hey that is great to hear that the volatile stuff is helping someone.

Just broadly speaking do you know if the instcombine bug involves pointer 
code vs. scalar?  I ask because intensive random testing has not found the 
bug that you are seeing.  That says that either (1) the bug lies in a part 
of the program space we don't explore or (2) it does, but we haven't run 
the tests for long enough.  The former sounds most likely to me.  If I 
knew more about what kind of code evoked the problem we could give high 
priority to adding the appropriate extensions to our testcase generator.

John




On Mon, 24 Nov 2008, Andrew Lenharth wrote:

> On Mon, Nov 24, 2008 at 10:51 AM, John Regehr <regehr at cs.utah.edu> wrote:
>>> was wrong.  At the time (~ 1 year ago) it was almost always
>>> instcombine and almost always volatile related.  Now bugpoint has some
>>> ways to run the code by some external agent which I haven't
>>> investigated yet.
>>
>> People have fixed a ton of bugs (volatile and otherwise) in instcombine
>> since then.  I will be very interested to hear what pass ends up being the
>> problem here, and what exactly is the code that triggers the bug-- please
>> post these when the results are known.
>
> Yes, the rash of volatile bug fixes made getting 2.6 working much much
> easier than getting 2.4 originally was.  Unfortunately I am in the
> middle of prepping a paper so I can't track down the current
> instcombine bug, but I've posted a building and working kernel should
> other people want to play with llvm compiled linux kernels.
>
> Andrew
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>