search for: compilationunit

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

...: in our case we weren't calling finalize(). As this manifests itself as exactly the same assertion failure as yours I suggest you double-check you are actually calling it before any passes run on the Module. Functionally, instead of maintaining a pointer to the CU in all Debug nodes, the main CompilationUnit node has a list of subprogram nodes. It is from this that a map gets generated of Subprogram -> CU. If such a mapping doesn't exist, the assertion you see (assuming it is the same as ours) fires. First thing I'd do is check the generated metadata. Is second-to-last parameter of the DW_T...

...calling finalize(). As this > manifests itself as exactly the same assertion failure as yours I suggest > you double-check you are actually calling it before any passes run on the > Module. > > Functionally, instead of maintaining a pointer to the CU in all Debug > nodes, the main CompilationUnit node has a list of subprogram nodes. It is > from this that a map gets generated of Subprogram -> CU. If such a mapping > doesn't exist, the assertion you see (assuming it is the same as ours) > fires. > > First thing I'd do is check the generated metadata. Is second-to-la...

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

...dy(Parser.java:1814) at com.sun.tools.javac.v8.parser.Parser.classDeclaration(Parser.java:1762) at com.sun.tools.javac.v8.parser.Parser.classOrInterfaceDeclaration(Parser.java:1734) at com.sun.tools.javac.v8.parser.Parser.typeDeclaration(Parser.java:1720) at com.sun.tools.javac.v8.parser.Parser.compilationUnit(Parser.java:1670) at com.sun.tools.javac.v8.JavaCompiler.parse(JavaCompiler.java:244) at com.sun.tools.javac.v8.JavaCompiler.parse(JavaCompiler.java:267) at com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:355) at com.sun.tools.javac.v8.Main.compile(Main.java:247) at com.sun.tools...

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,

...gt; references and that contain your prefered runtime code inlined. > > - Now, you have to solve the last problem, finding symbols from the > runtimeModule when they are not inlined (global values or functions). > In my case, I have defined my own SectionMemoryManager: > > class CompilationUnit : public llvm::SectionMemoryManager { > uint64_t getSymbolAddress(const std::string &Name) { > return (uint64_t)dlsym(SELF_HANDLE, Name.c_str() + 1); > /* + 1 with MacOS, + 0 with Linux */ > } > } > > which is called by MCJIT to resolve external sym...

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