search for: diagnosticinfo

Hello, I was thinking about printing SCEV into DiagnosticInfo messages, an example would be to print the loop trip count of loops, or the stride of memory accesses. I ran into two problems: - DiagnosticInfo is in Core, SCEV is in Analysis, so it is a little bit weird (I declare the operator<< overload for SCEV* in DiagnosticInfo, but only define it in...

..., false), llvm::Function::ExternalLinkage, "f2", module2); llvm::Function::Create(llvm::FunctionType::get(Type::getInt32Ty(*ctx3), false), llvm::Function::ExternalLinkage, "f3", module3); // merge f1 <- f2 Result = Linker::LinkModules(module1, module2, [&](const DiagnosticInfo &DI) {DI.print(DP);}); cout << "merge result=" << Result << endl; delete ctx2; cout << "--done merge #1--" << endl; // merge f3 <- f1 Result = Linker::LinkModules(module3, module1, [&](const DiagnosticInfo &DI) {DI.pr...

...ying the corresponding in-source "Kind" enumeration? As I play around with writing an AA pass, I'd like a good way to issue warnings for cases where my AA pass can't handle a particular IR construct. I was thinking to report those warnings via *llvm::LLVMContext::diagnose( const DiagnosticInfo & DI )*. None of the existing subclasses of *DiangosticInfo* seems quite appropriate for my needs, so I wanted to create my own subclass, outside of the LLVM source. So I'm stuck between (a) wanting all of my code to reside outside of the LLVM source, and (b) being obligated (I think) to...

...emitting diagnostic info, where one of the parameters was the severity level (llvm::DiagnosticSeverity). I'm particularly interested in drawing a distinction between "remarks" (which should be optionally filtered) and "warnings" (which should always be sent to errs()) The DiagnosticInfoOptimizationBase supports the exact set of details I care about. Unfortunately it's an abstract class, which is why I'm in my current situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/...

...:Function::ExternalLinkage, "f2", module2); > llvm::Function::Create(llvm::FunctionType::get(Type::getInt32Ty(*ctx3), false), llvm::Function::ExternalLinkage, "f3", module3); > > // merge f1 <- f2 > Result = Linker::LinkModules(module1, module2, [&](const DiagnosticInfo &DI) {DI.print(DP);}); > cout << "merge result=" << Result << endl; > delete ctx2; > cout << "--done merge #1--" << endl; > > // merge f3 <- f1 > Result = Linker::LinkModules(module3, module1, [&](const Diagno...

> On May 5, 2017, at 8:49 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > On 05/05/2017 10:44 AM, vivek pandya via llvm-dev wrote: >> Hello LLVM Devs, >> >> I have an idea to improve effectiveness of IR dump with -emit-after-all based on Adam Nemet's 2016 LLVM Dev presentation. >> I think we can track changes in each function, basic block and

...lvm::GlobalValue&) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 > #17 0x00007ffff6e61f23 in clang::ParseAST(clang::Sema&, bool, bool) () from /opt...

Hello, Is there a way to dump the Module IR with the SCEV as comment at the end of each line? The -analyze or -debug-pass is not printed on the IR itself. Maybe through the DiagnosticInfo? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/e178b4c8/attachment.html>

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

...&) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () >>> from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 >>> #17 0x00007ffff6e61f23 in clang::ParseAST(clang::Sema&, b...

...t/buildbot/lib/libLLVM-3.6svn.so > >>>> #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > >>>> #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () > >>>> from /opt/buildbot/lib/libLLVM-3.6svn.so > >>>> #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 > >>>> #17 0x00007ffff6e61f23 in clang::Pa...

.../libLLVM-3.6svn.so >>>>>>> #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>>>>>> #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () >>>>>>> from /opt/buildbot/lib/libLLVM-3.6svn.so >>>>>>> #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 >>>>>>> #17 0x00007fff...

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hello Duncan, Thank you for your reply. I did figure it out in the end. It was a linkage conflict between the modules. There were some global types that I was declaring in both modules. After removing them, linking worked perfectly. Still it's a mystery why I got no error string pointing me to the reason the linking failed in the first place. Best Regards, Lefteris(Eleftherios) Karapetsas

Hi All, I've been thinking lately about how to improve LLVM's error model and error reporting. A lack of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the

...uilder.cpp for Release+Asserts build llvm[1]: Compiling DataLayout.cpp for Release+Asserts build llvm[1]: Compiling DebugInfo.cpp for Release+Asserts build llvm[1]: Compiling DebugInfoMetadata.cpp for Release+Asserts build llvm[1]: Compiling DebugLoc.cpp for Release+Asserts build llvm[1]: Compiling DiagnosticInfo.cpp for Release+Asserts build llvm[1]: Compiling DiagnosticPrinter.cpp for Release+Asserts build llvm[1]: Compiling Dominators.cpp for Release+Asserts build llvm[1]: Compiling Function.cpp for Release+Asserts build llvm[1]: Compiling GCOV.cpp for Release+Asserts build llvm[1]: Compiling GVMateriali...