search for: modulebuild

Hi All, We want to compile LLVM/Clang and use the resulting headers/libraries in our project. But we compile it during out build process. I can build LLVM/Clang by adding it to our cmakelists.txt but when our code tries to use one of the headers (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If I do a 'make install' in the llvm directory, then the file is generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' step necessary even though I'm compiling llvm along with my code? TIA, ashok

> I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( Same here. > > - Michael Spencer Cheers, Rafael

...like that all the files and classes in the MC library > start with MC. This is c++, not c :( On a similar note, all the classes in clang/CodeGen are prefixed with CG or even CodeGen, could those be renamed as well? And speaking of the clang codegenerator, I as a llvm newbie was confused by the ModuleBuilder.h/.cpp. These files actually contain the definition of the CodeGenerator itself that I was searching for (being sort of the entry point of the codegenerator). I think it would be more clear if they were called CodeGenerator.h/.cpp. Or perhaps even splitted out into CodeGenerator.h and IR/CodeGen...

...mm.com> writes: > We want to compile LLVM/Clang and use the resulting > headers/libraries in our project. But we compile it during out build > process. I can build LLVM/Clang by adding it to our cmakelists.txt but > when our code tries to use one of the headers > (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If > I do a 'make install' in the llvm directory, then the file is > generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' > step necessary even though I'm compiling llvm along with my code? If you wish to use LLV...

...ta const*) llvm::ConstantFoldLoadThroughGEPConstantExpr(llvm::Constant*, llvm::ConstantExpr*) llvm::CallGraphLinkVar llvm::CallGraphSCCPass::assignPassManager(llvm::PMStack&, llvm::PassManagerType) vtable for llvm::CallGraphSCCPass ... and so on, then: ... /usr/local/lib/libclangCodeGen.a(ModuleBuilder.o) reference to undefined clang::ASTConsumer::InitializeTU(clang::TranslationUnit&) /usr/local/lib/libclangCodeGen.a(ModuleBuilder.o) reference to undefined clang::ASTConsumer::~ASTConsumer() ... /usr/local/lib/libclangCodeGen.a(CGObjC.o) reference to undefined vtable for clang::DeclRef...

...gt;> We want to compile LLVM/Clang and use the resulting >> headers/libraries in our project. But we compile it during out build >> process. I can build LLVM/Clang by adding it to our cmakelists.txt but >> when our code tries to use one of the headers >> (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If >> I do a 'make install' in the llvm directory, then the file is >> generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' >> step necessary even though I'm compiling llvm along with my code? > > I...

...e artifacts produced are different. Here are the issues I see: - configure doesnt seem to respect '--prefix' option, it just puts everything in the build directory - configure doesnt create the include dir under "Release+Asserts" - configure doesnt create files like clang/CodeGen/ModuleBuilder.h The list of artifacts is attached. Any pointers? The commands I used are: > cmake -G "$cmake_args" -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_INSTALL_PREFIX="../bin" ../src > ../src/configure --prefix=$PWD/../bin --ena...

...ome IRGenFunction. CGCall.cpp would become... probably either GenCall.cpp or IRGenCall.cpp, with my preference being the shortest that's still unambiguous throughout the project, which I think means Gen*. > And speaking of the clang codegenerator, I as a llvm newbie was > confused by the ModuleBuilder.h/.cpp. These files actually contain the > definition of the CodeGenerator itself that I was searching for (being > sort of the entry point of the codegenerator). > > I think it would be more clear if they were called > CodeGenerator.h/.cpp. Or perhaps even splitted out into >...

...t bug report), and 'bindtests.pl' is also not installed. However the empty file 'Guestfs.bs' is now copied in, but in Fedora we were already removing any '*.bs' files. This is good reading (make sure to read the comments too): http://blogs.perl.org/users/rurban/2011/01/why-modulebuild-sucks.html Rich.

.../CodeGen/CodeGenModule.cpp:399 > ---Type <return> to continue, or q <return> to quit--- > #44 0x00007fb71166b523 in (anonymous > namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x4ceb9c0, > Ctx=...) > at > /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:267 > #45 0x00007fb71163ff48 in > clang::BackendConsumer::HandleTranslationUnit (this=0x49fc8d0, C=...) > at > /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:283 > #46 0x00007fb711dbf5f5 in > clang::MultiplexConsumer::HandleTranslationUnit (this=0x2cc...

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

...e::EmitTopLevelDecl (this=0xd63cf0, D=0xd6a090) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenModule.cpp:2783 #53 0x00007ffff4cdaf54 in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0xd5cde0, DG=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/ModuleBuilder.cpp:69 #54 0x00007ffff4332dd3 in lldb_private::ASTResultSynthesizer::HandleTopLevelDecl (this=0xd5e320, D=...) at /home/athirumurthi/git/lldb/tools/lldb/source/Expression/ASTResultSynthesizer.cpp:125 #55 0x00007ffff4ef055c in clang::ParseAST (S=..., PrintStats=false, SkipFunctionBodies=false)...

...nModule.cpp:399 >> ---Type <return> to continue, or q <return> to quit--- >> #44 0x00007fb71166b523 in (anonymous >> namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x4ceb9c0, >> Ctx=...) >> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:267 >> #45 0x00007fb71163ff48 in >> clang::BackendConsumer::HandleTranslationUnit (this=0x49fc8d0, C=...) >> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:283 >> #46 0x00007fb711dbf5f5 in >> clang::MultiplexConsumer::HandleTranslationU...

...odule::EmitTopLevelDecl(clang::Decl*) /export/users/amitrokh/llvm-sanitizer/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp:3508:5 #10 0x3a247bd in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) /export/users/amitrokh/llvm-sanitizer/llvm/tools/clang/lib/CodeGen/ModuleBuilder.cpp:125:9 #11 0x3a21c09 in clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) /export/users/amitrokh/llvm-sanitizer/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:118:7 #12 0x4552dc8 in clang::ParseAST(clang::Sema&, bool, bool) /export/users/amitrokh/llvm-sanitizer/llvm/t...

...e::EmitTopLevelDecl (this=0xd63cf0, D=0xd6a090) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CodeGenModule.cpp:2783 #53 0x00007ffff4cdaf54 in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0xd5cde0, DG=...) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/ModuleBuilder.cpp:69 #54 0x00007ffff4332dd3 in lldb_private::ASTResultSynthesizer::HandleTopLevelDecl (this=0xd5e320, D=...) at /home/athirumurthi/git/lldb/tools/lldb/source/Expression/ASTResultSynthesizer.cpp:125 #55 0x00007ffff4ef055c in clang::ParseAST (S=..., PrintStats=false, SkipFunctionBodies=false)...

...return> to continue, or q <return> to quit--- > >>> #44 0x00007fb71166b523 in (anonymous > >>> namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x4ceb9c0, > >>> Ctx=...) > >>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:267 > >>> #45 0x00007fb71163ff48 in > >>> clang::BackendConsumer::HandleTranslationUnit (this=0x49fc8d0, C=...) > >>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:283 > >>> #46 0x00007fb711dbf5f5 in > >>&gt...

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

...return> to quit--- > >>>>> #44 0x00007fb71166b523 in (anonymous > >>>>> namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x4ceb9c0, > >>>>> Ctx=...) > >>>>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:267 > >>>>> #45 0x00007fb71163ff48 in > >>>>> clang::BackendConsumer::HandleTranslationUnit (this=0x49fc8d0, C=...) > >>>>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:283 > >>>>> #46 0x000...

...quit--- >>>>>>> #44 0x00007fb71166b523 in (anonymous >>>>>>> namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x4ceb9c0, >>>>>>> Ctx=...) >>>>>>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:267 >>>>>>> #45 0x00007fb71163ff48 in >>>>>>> clang::BackendConsumer::HandleTranslationUnit (this=0x49fc8d0, C=...) >>>>>>> at /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:283 >>>>>>&...