search for: libclangcodegen

...43742 WITHOUT_LIB32=yes WITHOUT_PROFILE=yes WITHOUT_SYSINSTALL=yes WITH_CLANG=yes WITH_CLANG_EXTRAS=yes WITH_CLANG_IS_CC=yes WITH_LIBCPLUSPLUS=yes CPUTYPE?=athlon64-sse3 CXXFLAGS+= -stdlib=libc++ -std=c++11 CC=clang CPP=clang-cpp CXX=clang++ NO_WERROR= WERROR= #NO_FSCHG= [...] ===> lib/clang/libclangcodegen (all) [...] clang++ -O2 -pipe -I/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/usr/src/lib/clang/libclangcode...

As a note, I experimentally attempted to build 391 branch "just llvm + clang" on ubuntu the other day, and got this: [ 90%] Linking CXX executable ../../../../bin/clang ../../../../lib/libclangCodeGen.a(ObjectFilePCHContainerOperations.cpp.o): In function `(anonymous namespace)::PCHContainerGenerator::DebugTypeVisitor::VisitImportDecl(clang::ImportDecl*)': /home/rdp/dev/llvm/llvm/tools/clang/lib/CodeGen/ObjectFilePCHContainerOperations.cpp:76: undefined reference to `clang::CodeGen::CGDebugI...

...st&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/lib/libLLVMCore.so.3.8+0x19e57f) #19 0xfffffffff50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734) #20 0xfffffffff59fc72c clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/libclangCodeGen.so.3.8+0x6972c) #21 0xfffffffff5b2cd85 clang::ASTFrontendAction::ExecuteAction() (/usr/lib/libclangCodeGen.so.3.8+0x199d85) #22 0xfffffffff3b2b294 clang::CodeGenAction::ExecuteAction() (/usr/lib/libclangParse.so.3.8+0x24294) #23 0xfffffffff582583e clang::FrontendAction::Execute() (/usr/lib/libclang...

...tract away the installed runtimes. That way, applications can link against the ICD loader instead of the actual runtimes, which makes it more portable. This does also allow distributions to ship support for all the various OpenCL runtimes out there. The problem is that some OpenCL runtimes link libclangCodeGen statically (where the offending cli arguments are defined), and libLLVM dynamically. The ICD loader has to load every runtime on the system in order to determine which one to use. When an affected runtime is loaded, it registers the cli arguments from the static libclangCodeGen in the dynamic l...

...t; That way, applications can link against the ICD loader instead of the actual >> runtimes, which makes it more portable. This does also allow distributions to >> ship support for all the various OpenCL runtimes out there. >> >> The problem is that some OpenCL runtimes link libclangCodeGen statically >> (where the offending cli arguments are defined), and libLLVM dynamically. >> >> The ICD loader has to load every runtime on the system in order to determine >> which one to use. When an affected runtime is loaded, it registers the cli >> arguments from th...

...1/builders/lldb-x86_64-freebsd/builds/4668/steps/compile/logs/stdio Assertion: Assertion failed: ((!DD->isTrivial() || DD->hasAttr<DLLExportAttr>()) && "Should not emit dtor epilogue for non-exported trivial dtor!"), function EnterDtorCleanups, file /usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGClass.cpp, line 1429. Galina, is it possible to get the /tmp/CommandLine-26c092.cpp and .sh from the bot?

...ed runtimes. > That way, applications can link against the ICD loader instead of the actual > runtimes, which makes it more portable. This does also allow distributions to > ship support for all the various OpenCL runtimes out there. > > The problem is that some OpenCL runtimes link libclangCodeGen statically > (where the offending cli arguments are defined), and libLLVM dynamically. > > The ICD loader has to load every runtime on the system in order to determine > which one to use. When an affected runtime is loaded, it registers the cli > arguments from the static libclangCo...

Dear testers, 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. This took a little longer than I'd hoped, but I think the branch is in a decent state now. There are still open merge requests and bugs, but I'd like to get the real testing started to see where we're at. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs,

...code 3 to program with LLVM and Clang (both about yesterday's latest revisions), and when I compile, I get 1501 link-time warnings. All those I read were about symbol visibility. Here's an example: ld: warning: namespace::class::method() has different visibility (default) in /usr/local/lib/libclangCodeGen.a(CodeGenAction.o) and (hidden) in /Users/myself/Projets/path/build/project.build/Debug/project.build/Objects-normal/x86_64/object.o 1501 seems large enough that it could simply be all symbols referenced from the static libraries. It works anyways though. What am I doing wrong? As usual with stuff...

...lications can link against the ICD loader instead of the actual >>> runtimes, which makes it more portable. This does also allow distributions to >>> ship support for all the various OpenCL runtimes out there. >>> >>> The problem is that some OpenCL runtimes link libclangCodeGen statically >>> (where the offending cli arguments are defined), and libLLVM dynamically. >>> >>> The ICD loader has to load every runtime on the system in order to determine >>> which one to use. When an affected runtime is loaded, it registers the cli >>&g...

...n*, llvm::TargetData 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...

...essiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a -lpthread lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a lib/libclangSerialization.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMMIRParser.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARM...

...-10.0.0-rc5 > > > > If nothing new comes up, I plan to tag 'final' on Monday. Testers, if > > you still have cycles, please take this for a quick spin. > > I went ahead and updated all Zig's CI to use rc5, and ran into this problem: > > /usr/lib/llvm-10/lib/libclangCodeGen.a(BackendUtil.cpp.o): In function > `(anonymous > namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, > std::unique_ptr<llvm::raw_pwrite_stream, > std::default_delete<llvm::raw_pwrite_stream> >)': > BackendUtil.cpp:(.text._ZN12_GLOBAL_...

...icBlock*, bool, llvm::TargetLibraryInfo const*) + 3782 7 libLLVMScalarOpts.3.7.0.dylib 0x000000010867905b (anonymous namespace)::IPSCCP::runOnModule(llvm::Module&) + 6043 8 libLLVMCore.3.7.0.dylib 0x0000000108131aa3 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1123 9 libclangCodeGen.3.7.0.dylib 0x0000000109ea94da clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 7866 10 libclangCodeGen.3....

...program with LLVM and Clang (both about yesterday's latest revisions), and when I compile, I get 1501 link-time warnings. All those I read were about symbol visibility. Here's an example: > > ld: warning: namespace::class::method() has different visibility (default) in /usr/local/lib/libclangCodeGen.a(CodeGenAction.o) and (hidden) in /Users/myself/Projets/path/build/project.build/Debug/project.build/Objects-normal/x86_64/object.o > > 1501 seems large enough that it could simply be all symbols referenced from the static libraries. It works anyways though. > What am I doing wrong? As u...

...essiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a -lpthread lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a lib/libclangSerialization.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMMIRParser.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARM...

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

...b/libLLVMCore.a lib/libLLVMipo.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a -lpthread lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDe...

...ntationRuntimeThreadSanitizer.a lib/liblldbPluginSystemRuntimeMacOSX.a lib/liblldbPluginProcessElfCore.a lib/liblldbPluginJITLoaderGDB.a lib/liblldbPluginExpressionParserClang.a lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginProcessLinux.a lib/liblldbPluginProcessPOSIX.a -Wl,--end-group lib/libclangCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMCoverage.a lib/libLLVMipo.a lib/libLLVMVectorize.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMInstrumentation.a lib/libLLVMLinker.a lib/libLLVMObjCARCOpts.a lib/libLLVMObject.a lib/libLLVMScalarOpts.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a lib/...

...lib/libLLVMipo.a > lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a > lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a > lib/libLLVMScalarOpts.a lib/libLLVMSupport.a > lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a lib/libclangBasic.a > lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a > lib/libclangFrontendTool.a lib/libLLVMAsmPrinter.a > lib/libLLVMSelectionDAG.a lib/libLLVMCodeGen.a > lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMX86Info.a > lib/libLLVMMCDisassembler.a lib/libclangCodeGen.a lib/libLLVMipo....