search for: emiterror

...th compilation > even though the inline asm was not valid. I'm not sure that there is value > in trying to make the backend continue compiling code that most likely has > no meaning. I'm not 100% convinced that is the case here. The inline asm errors are reported via LLVMContext::emitError, which has this documentation: /// emitError - Emit an error message to the currently installed error handler /// with optional location information. This function returns, so code should /// be prepared to drop the erroneous construct on the floor and "not crash". /// The gener...

...in RegAllocFast.cpp in compiling one source file in test-suite as the result of a new Mips fast-isel patch I was testing. It apparently just generates bad code and continues? // Nothing we can do. Report an error and keep going with a bad allocation. if (MI->isInlineAsm()) MI->emitError("inline assembly requires more registers than available"); else MI->emitError("ran out of registers during register allocation"); How is it possible to run out of registers during register allocation? Lol. Reed

...the result of a new Mips fast-isel patch >> I was testing. >> >> It apparently just generates bad code and continues? >> >> // Nothing we can do. Report an error and keep going with a bad >> allocation. >> if (MI->isInlineAsm()) >> MI->emitError("inline assembly requires more registers than >> available"); >> else >> MI->emitError("ran out of registers during register allocation"); >> >> >> How is it possible to run out of registers during register >> allocation? Lol....

...> >> This seems to only handle fatal errors. If that's correct, it will >> probably need to be extended to handle non-fatal errors, warnings, >> suggestions, notes, etc. > > > Okay, it looks like the combination of llvm/Support/ErrorHandling.h and > LLVMContext::emitError solves a part of my use case.  I found the > CrashRecoveryContext class, which seems to allow me to intercept the > report_fatal_error() calls by installing a custom handler that writes to a > custom stream and then calls abort() instead of the default exit(). >  Alternatively, it looks...

...m/Support/ErrorHandling.h > > This seems to only handle fatal errors. If that's correct, it will > probably need to be extended to handle non-fatal errors, warnings, > suggestions, notes, etc. > Okay, it looks like the combination of llvm/Support/ErrorHandling.h and LLVMContext::emitError solves a part of my use case. I found the CrashRecoveryContext class, which seems to allow me to intercept the report_fatal_error() calls by installing a custom handler that writes to a custom stream and then calls abort() instead of the default exit(). Alternatively, it looks like I can just spa...

On Sun, 03 Jun 2012 12:12:06 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > If I may add my two cents: > > > > I am planning to use LLVM as the backend for a compiler I am > > working on. And I wholeheartedly agree with Justin that it is a > > problem, if LLVM is allowed to freely

...ly handle fatal errors. If that's correct, it will > >> probably need to be extended to handle non-fatal errors, warnings, > >> suggestions, notes, etc. > > > > > > Okay, it looks like the combination of llvm/Support/ErrorHandling.h and > > LLVMContext::emitError solves a part of my use case. I found the > > CrashRecoveryContext class, which seems to allow me to intercept the > > report_fatal_error() calls by installing a custom handler that writes to > a > > custom stream and then calls abort() instead of the default exit(). > >...

...If that's correct, it will >> >> probably need to be extended to handle non-fatal errors, warnings, >> >> suggestions, notes, etc. >> > >> > >> > Okay, it looks like the combination of llvm/Support/ErrorHandling.h and >> > LLVMContext::emitError solves a part of my use case.  I found the >> > CrashRecoveryContext class, which seems to allow me to intercept the >> > report_fatal_error() calls by installing a custom handler that writes to >> > a >> > custom stream and then calls abort() instead of the defa...

Hi all, I'd like to add a new diagnostic handler to llc. Right now, llc doesn't have one at all, and instead just exits after the first error that it encounters. This is very different from the behaviour of clang and other front ends, who try to report as many errors as possible before exiting. I think this is very important for testing LLVM's CodeGen in a more robust fashion. For

There are times that I want to generate an ERROR, but not stop processing of the code. An example of this would be when I find there is a value out of range for a specific operand. producing the error for all instances of this class of errors would be good. Also, I would like to have the error message have some relationship to the offending source. Thanks, Jack -------------- next part

On Fri, Jul 1, 2011 at 4:09 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal

On Jul 1, 2011, at 4:08 PM, Jakob Stoklund Olesen wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal error: error in backend: Inline

I want to report a problem with an inline assembly instruction from a code generator pass? How can I do that with the proper diagnostic format and source location? Right now we only get: clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c fatal error: error in backend: Inline asm output regs must be last on the x87 stack But gcc-4-2 can: $ gcc-4.2 -c

I want to report a problem with an inline assembly instruction from a code generator pass? How can I do that with the proper diagnostic format and source location? Right now we only get: clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c fatal error: error in backend: Inline asm output regs must be last on the x87 stack But gcc-4-2 can: $ gcc-4.2 -c

Hi, When compiling mumble-iphone from https://github.com/mumble-voip/mumble-iphoneos <https://github.com/mumble-voip/mumble-iphoneos> I had a parser error on the file CodeOutputStream.m (form https://github.com/booyah/protobuf-objc/tree/696b7b61cdd4e8d77c55ace98b3119194fa04b7f <https://github.com/booyah/protobuf-objc/tree/696b7b61cdd4e8d77c55ace98b3119194fa04b7f>). I know that the