[LLVMdev] LTO regression test Bug 17623

[David Blaikie]

On Wed, Feb 4, 2015 at 11:05 AM, David Callahan <dcallahan at fb.com> wrote:

>  Thanks for the reply.
>
>  The bug is in the alias analysis (lib/Analysis/IPA/GlobalsModRef.cpp)
> where a variable is not correctly seen as address-taken due to a static
> initializer. This leads to an invalid loop invariant code motion and a
> subsequent use of a bad pointer.
>

Are there other tests for GlobalsModRef? You could check in test/Analysis
for them (or look at the blame history of GlobalsModRef.cpp and see how
other changes were tested) to get an idea of how to test changes to that
Analysis.


>
>  So clang is correct but  lto introduces a problem. I tried but was
> unable to reproduce the problem with opt.
> The bug can be reproduced with a .ll file but I don’t know how to verify
> the fix other than running the output of LTO and so would welcome any
> suggestions.
>
>  david
>
>
>   From: David Blaikie <dblaikie at gmail.com>
> Date: Tuesday, February 3, 2015 at 6:20 PM
> To: David Callahan <dcallahan at fb.com>
> Cc: LLVM Dev Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] LTO regression test Bug 17623
>
>
> On Feb 3, 2015 5:57 PM, "David Callahan" <dcallahan at fb.com> wrote:
> >
> > Hello,
> >
> > I have a fix for Bug17623 (http://llvm.org/bugs/show_bug.cgi?id=17623
> <https://urldefense.proofpoint.com/v1/url?u=http://llvm.org/bugs/show_bug.cgi?id%3D17623&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=8am7JZUn9ir%2BIPWQGSonqw%3D%3D%0A&m=%2B%2Bkxr1kNzm83C5RPkRlha1d0eUWXp7eVGgXWS%2F0MCDk%3D%0A&s=1fa398a9f03fc233090f7998fbbfd44c2cac26608bd90c07657af5f21ae80c85>)
> but I am not sure how best to install a regression test. The commands I use
> to run the test are (approximately)
> >
> > $LLVM/clang -flto -O2 -o BUG.o -c  BUG.c
> > $LLVM/llvm-lto -exported-symbol=main -o lto.o BUG.o
> > $LLVM/clang -o bug lto.o
> > ./bug
> >
> > Where the failing behavior is to seg fault and corrected behavior is to
> run to completion.
> > The use of llvm-lto avoids a dependence on the native loader having
> appropriate plugin support.
> >
> > The reliance on running clang and code suggests a test belongs in the
> llvm-test-suite.
>
> Not necessarily. It depends where the bug is. If clang is producing wrong
> IR and needs to be changed, we just test clang and verify that the desired
> IR doesn't have the erroneous feature that wr removed.
>
> Alternatively, if clang is doing the right thing and the llvm IR linker is
> mangling the result, or the llvm optimizations misunderstand - we should
> just be able to construct the minimal IR that demonstrates the poor
> behavior and verify llvm gets the right answer.
>
> So where is the bug?
>
> > Could someone give me a pointer on how to configure a test using
> commands like the above? Are there any other tests with a
>
> similar structure?
> >
> > Thanks
> > david
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> <https://urldefense.proofpoint.com/v1/url?u=http://llvm.cs.uiuc.edu&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=8am7JZUn9ir%2BIPWQGSonqw%3D%3D%0A&m=%2B%2Bkxr1kNzm83C5RPkRlha1d0eUWXp7eVGgXWS%2F0MCDk%3D%0A&s=0cedb0184fc7b6271a3c209b247d747a6fe6d472e45329ba4b00fec538753bf4>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> <https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=8am7JZUn9ir%2BIPWQGSonqw%3D%3D%0A&m=%2B%2Bkxr1kNzm83C5RPkRlha1d0eUWXp7eVGgXWS%2F0MCDk%3D%0A&s=218b66c9dbe88e4a2ec30bfbe22cf49fa5e5dfe6b5e774878f4782d056fc2c90>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150204/48fe52e8/attachment.html>