search for: diagnostichandler

Hi all, Just a heads up that I'm working on Errorifying the bitcode reader. Basically any errors that are currently being reported with the DiagnosticHandler would now be reported with an Error instead. It's turning out to be a rather large patch, but it should permit some much needed cleanups (e.g. not requiring an LLVMContext in some parts of the bitcode reader interface simply in order to provide a diagnostic handler) so I'm looking forward...

On Wed, Feb 10, 2016 at 10:50 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of how I should change our code? Should I bug someone else about this problem? Should this API change be documented in

Hello, I am working on backend development and would like to utilize my target's MCAsmParser inside of an MCInst-level class implementation. I noticed that the AsmParser is registered with the target registry however I am having no luck grepping for a "template" of how to instantiate it and have yet to find specific documentation on how it is done. Any ideas or help is greatly

> I would like a command line option to disable this optimization. That way tests can still verify that EVEX instructions came out of isel by using -show-mc-encoding. I think that keeping tests compatibility is not a reason for an additional “llc” flag. We check encoding in test/MC/X86 dir. Is there any option to report-out from llc in non-debug mode? It should be an option to control

Hi everyone, Having proper error handling in LLVM's Object parsing library is a nice thing by itself, but it would additionally allow us to find bugs by fuzzing (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean input validation is essential. This is a generic discussion of state of affairs. I want to do some progress in fuzzing before we finish it (especially if we