Hi Duncan, Thanks for your reply. I did try the method suggested by you. I got a foo.bc with -emit-llvm switch. llc on foo.bc gets me the same assertion failure, as you pointed out. Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and bugpoint-reduced-function.bc. My previous experience is that if I compile either if them, I would get the same failure as I did with foo.bc. That is not the case. I get a different assertion failure when I compile either of them with llc which is as follows: llc: <llvm-src>/llvm/lib/CodeGen/AsmPrinter/DwarfWriter.cpp:2808: void llvm::DwarfDebug::ConstructCompileUnits(): Assertion `Root->hasLinkOnceLinkage() && Root->hasOneUse() && "Malformed compile unit descriptor anchor type"' failed. This makes it hard for me to easily create a test case and submit a bug report. Hence, I thought I should take this opportunity to delve deeper into LLVM and look at this issue. Any further nudges / help is highly appreciated! Thanks, Bharadwaj On Wed, Mar 4, 2009 at 3:59 PM, Duncan Sands <baldrick at free.fr> wrote:> Hi Bharadwaj, > > > I get the following error during compilation using the LLVM > cross-compiler > > (x86_64->arm). > > > > error: nested functions are disabled, use -fnested-functions to re-enable > > yes, nested functions are disabled by default in llvm-gcc (not sure why - > maybe a historical hang over from the days when they were not supported?). > > > With -fnested-functions switch, I get the following error: > > > > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual > > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, > > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom lower > > this!"' failed. > > frobos/tests/hello.c:453: internal compiler error: Aborted > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <URL:http://developer.apple.com/bugreporter> for instructions. > > > > I'd like to investigate this but am wondering if anyone has any > > thoughts/suggestions in this area. > > I don't know anything about cross-compiling, but the usual way > to debug this kind of thing is to re-run by hand the line that > caused this assertion, but adding -emit-llvm to the command line. > The output will then contain LLVM bitcode. If you are lucky, > then running llc on the bitcode will give the same assertion > failure. If so, then "bugpoint --run-llc the_bit_code" should > automatically reduce a minimal testcase. > > Ciao, > > Duncan. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090304/062f9e81/attachment.html>
On Mar 4, 2009, at 1:33 PM, S. Bharadwaj Yadavalli wrote:> Hi Duncan, > > Thanks for your reply. > > I did try the method suggested by you. I got a foo.bc with -emit- > llvm switch. llc on foo.bc gets me the same assertion failure, as > you pointed out. > > Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and > bugpoint-reduced-function.bc. My previous experience is that if I > compile either if them, I would get the same failure as I did with > foo.bc. That is not the case. I get a different assertion failure > when I compile either of them with llc which is as follows: > > llc: <llvm-src>/llvm/lib/CodeGen/AsmPrinter/DwarfWriter.cpp:2808: > void llvm::DwarfDebug::ConstructCompileUnits(): Assertion `Root- > >hasLinkOnceLinkage() && Root->hasOneUse() && "Malformed compile > unit descriptor anchor type"' failed.This is because bugpoint tool does not understand debug info intrinsics. To avoid this, when you generate foo.bc with -emit-llvm switch, do not use -g on the llvm-gcc command line. - Devang> > > This makes it hard for me to easily create a test case and submit a > bug report. > > Hence, I thought I should take this opportunity to delve deeper into > LLVM and look at this issue. > > Any further nudges / help is highly appreciated! > > Thanks, > > Bharadwaj > > On Wed, Mar 4, 2009 at 3:59 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bharadwaj, > > > I get the following error during compilation using the LLVM cross- > compiler > > (x86_64->arm). > > > > error: nested functions are disabled, use -fnested-functions to re- > enable > > yes, nested functions are disabled by default in llvm-gcc (not sure > why - > maybe a historical hang over from the days when they were not > supported?). > > > With -fnested-functions switch, I get the following error: > > > > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual > > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, > > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom > lower > > this!"' failed. > > frobos/tests/hello.c:453: internal compiler error: Aborted > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <URL:http://developer.apple.com/bugreporter> for instructions. > > > > I'd like to investigate this but am wondering if anyone has any > > thoughts/suggestions in this area. > > I don't know anything about cross-compiling, but the usual way > to debug this kind of thing is to re-run by hand the line that > caused this assertion, but adding -emit-llvm to the command line. > The output will then contain LLVM bitcode. If you are lucky, > then running llc on the bitcode will give the same assertion > failure. If so, then "bugpoint --run-llc the_bit_code" should > automatically reduce a minimal testcase. > > Ciao, > > Duncan. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev- Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090304/15585c1a/attachment.html>
Nice! Thanks for the tip, Devang. That helped. Bharadwaj On Wed, Mar 4, 2009 at 4:46 PM, Devang Patel <dpatel at apple.com> wrote:> > On Mar 4, 2009, at 1:33 PM, S. Bharadwaj Yadavalli wrote: > > Hi Duncan, > > Thanks for your reply. > > I did try the method suggested by you. I got a foo.bc with -emit-llvm > switch. llc on foo.bc gets me the same assertion failure, as you pointed > out. > > Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and > bugpoint-reduced-function.bc. My previous experience is that if I compile > either if them, I would get the same failure as I did with foo.bc. That is > not the case. I get a different assertion failure when I compile either of > them with llc which is as follows: > > llc: <llvm-src>/llvm/lib/CodeGen/AsmPrinter/DwarfWriter.cpp:2808: void > llvm::DwarfDebug::ConstructCompileUnits(): Assertion > `Root->hasLinkOnceLinkage() && Root->hasOneUse() && "Malformed compile unit > descriptor anchor type"' failed. > > > This is because bugpoint tool does not understand debug info intrinsics. > To avoid this, when you generate foo.bc with -emit-llvm switch, do not use > -g on the llvm-gcc command line. > > - > Devang > > > > This makes it hard for me to easily create a test case and submit a bug > report. > > Hence, I thought I should take this opportunity to delve deeper into LLVM > and look at this issue. > > Any further nudges / help is highly appreciated! > > Thanks, > > Bharadwaj > > On Wed, Mar 4, 2009 at 3:59 PM, Duncan Sands <baldrick at free.fr> wrote: > >> Hi Bharadwaj, >> >> > I get the following error during compilation using the LLVM >> cross-compiler >> > (x86_64->arm). >> > >> > error: nested functions are disabled, use -fnested-functions to >> re-enable >> >> yes, nested functions are disabled by default in llvm-gcc (not sure why - >> maybe a historical hang over from the days when they were not supported?). >> >> > With -fnested-functions switch, I get the following error: >> > >> > <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual >> > llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, >> > llvm::SelectionDAG&): Assertion `0 && "Don't know how to custom lower >> > this!"' failed. >> > frobos/tests/hello.c:453: internal compiler error: Aborted >> > Please submit a full bug report, >> > with preprocessed source if appropriate. >> > See <URL:http://developer.apple.com/bugreporter> for instructions. >> > >> > I'd like to investigate this but am wondering if anyone has any >> > thoughts/suggestions in this area. >> >> I don't know anything about cross-compiling, but the usual way >> to debug this kind of thing is to re-run by hand the line that >> caused this assertion, but adding -emit-llvm to the command line. >> The output will then contain LLVM bitcode. If you are lucky, >> then running llc on the bitcode will give the same assertion >> failure. If so, then "bugpoint --run-llc the_bit_code" should >> automatically reduce a minimal testcase. >> >> Ciao, >> >> Duncan. >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > - > Devang > > > > > _______________________________________________ > 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/20090304/c91cc7f6/attachment.html>