search for: compilationunits

Displaying 8 results from an estimated 8 matches for "compilationunits".

Did you mean: compilationunit
2011 Sep 24
2
[LLVMdev] DIBuilder - what's with the null compile units?
Hi, Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't. I'll take a look at this on Monday, if it is a bug in LLVM. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Devang Patel Sent: 23 September 2011 21:06 To: Talin...
2011 Sep 26
0
[LLVMdev] DIBuilder - what's with the null compile units?
...evang Patel; Talin Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units? Hi, Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't. I'll take a look at this on Monday, if it is a bug in LLVM. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Devang Patel Sent: 23 September 2011 21:06 To: Talin...
2011 Oct 23
2
[LLVMdev] DIBuilder - what's with the null compile units?
...opers Mailing List > Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units? > > Hi, > > Thanks for bringing this up, I'm just about to investigate an identical > case which has broken our front-end. Both ours and clang generate > subroutineinfo with null compilationunits, but ours asserts and clang's > doesn't. > > I'll take a look at this on Monday, if it is a bug in LLVM. > > Cheers, > > James > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of De...
2011 Sep 23
0
[LLVMdev] DIBuilder - what's with the null compile units?
On Sep 23, 2011, at 12:39 PM, Talin wrote: > Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a
2003 Oct 03
3
openoffice port build on FreeBSD 4.9
I am very new to FreeBSD and Unix in general. I may have more problems than I think, but here goes. I am trying to make depend && install WITH_BSD_JDK=TRUE clean with openoffice. Everything works fine until I get to the jvm section (seen below). I have tried looking for this on the net, but I have not been to successful in finding a solution. Thanks for your help. Stephen
2011 Sep 23
3
[LLVMdev] DIBuilder - what's with the null compile units?
Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine. I took a look at the code in DIBuilder.cpp,
2014 Jan 26
2
[LLVMdev] MCJIT versus getLazyBitcodeModule?
Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,
2014 Jan 21
4
[LLVMdev] MCJIT versus getLazyBitcodeModule?
Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not