search for: llvm_report_error

...or desirable for them to cause a "recoverable error", even ignoring the fact that there is no good recovery mechanism. I want to reiterate what Eli said, it is worth repeating: " > So what should we use to validate input, such as constructing an > APFloat from a string? llvm_report_error? Or should I change my string > parsing function into a classmethod that returns pointer to an APFloat > or null on failure? Nothing in ADT should be using llvm_report_error; if something is expected to fail, it should return an error code, and otherwise it should assert." In other wo...

> To be fully clear, I'm not a big fan of the current llvm_report_error > approach (though it is definitely better than what we had before!). > In my ideal little world, when the backend invokes llvm_report_error, > it should *guarantee* that it can continue on and return back.  For > example, in an inline asm error, I think the code generator should > r...

Eli Friedman <eli.friedman at gmail.com> writes: >> As LLVM is really a library it should behave like one and not just abort the >> whole process on an assert. > > This isn't Java; if we hit an assert, it's likely memory is in an > inconsistent state, so we don't want to try to recover. This over-used argument about "memory likely is in an inconsistent

On Wed, Aug 19, 2009 at 5:27 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > As LLVM is really a library it should behave like one and not just abort the > whole process on an assert. This isn't Java; if we hit an assert, it's likely memory is in an inconsistent state, so we don't want to try to recover. -Eli

...ner at apple.com> wrote: > > assert and abort should never happen, just like a null pointer or > garbage pointer dereference should never happen.  How are garbage > pointer and asserts different? So what should we use to validate input, such as constructing an APFloat from a string? llvm_report_error? Or should I change my string parsing function into a classmethod that returns pointer to an APFloat or null on failure?

.../llvm.org/bugs/show_bug.cgi?id=5466) how about making lli inform > the user that LLVM was built without FFI support? Thanks for the reminder. I recall looking at the patch but I didn't apply it at the time because I couldn't figure out why the code above it used errs() in one case and llvm_report_error in another. Nick

Nick Lewycky <nicholas at mxc.ca> writes: > The interpreter uses libffi to make external function calls. However, it > needs to be detected at LLVM's compile time. If you're using the > released packages, we disabled that because we were worried about users > who don't have libffi installed. This seems to be quite a common problem (I too hit it once, thought it

Nick Lewycky <nicholas at mxc.ca> writes: > Thanks for the reminder. I recall looking at the patch but I didn't > apply it at the time because I couldn't figure out why the code above > it used errs() in one case and llvm_report_error in another. What was the reason? (I think I too wondered that.)

...=5466) how about making lli inform >> the user that LLVM was built without FFI support? >> > > Thanks for the reminder. I recall looking at the patch but I didn't apply > it at the time because I couldn't figure out why the code above it used > errs() in one case and llvm_report_error in another. > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091118/585c0a53/attachment.html>

...lli inform >>> the user that LLVM was built without FFI support? >>> >> >> Thanks for the reminder. I recall looking at the patch but I didn't apply >> it at the time because I couldn't figure out why the code above it used >> errs() in one case and llvm_report_error in another. >> >> Nick >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091118/e40ace84/attachment.html>

...inform > the user that LLVM was built without FFI support? > > > Thanks for the reminder. I recall looking at the patch but I > didn't apply it at the time because I couldn't figure out why > the code above it used errs() in one case and llvm_report_error > in another. > > Nick > > >

Hi, What's the proper way to abort a pass if something goes wrong (e.g., in the pass's constructor)? Do I simply call abort()? I looked through the existing passes but didn't see an example of this. Thanks, Trevor

On Mar 1, 2010, at 11:04 AM, Trevor Harmon wrote: > What's the proper way to abort a pass if something goes wrong (e.g., > in the pass's constructor)? Do I simply call abort()? Calling abort() causes a stack dump to the console, which is good for serious errors, but overkill for most other types of error situations, such as a command-line parameter that the user forgot to add.

...the user that LLVM was built without FFI support? >> >> >> Thanks for the reminder. I recall looking at the patch but I >> didn't apply it at the time because I couldn't figure out why >> the code above it used errs() in one case and llvm_report_error >> in another. >> >> Nick >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091118/f2f4f7ab/attachment.html>

...m.org/docs/CodingStandards.html#ll_avoidendl 13. You use "std::ostream" a lot. Would it be appropriate to use "raw_ostream" instead? 14. In DisassemblerTables::setTableFields, you emit things to "std::cerr". Use "errs()" instead. Or, better yet, "llvm_report_error". :-) 15. Prefer pre-increment/decrement for variables: http://llvm.org/docs/CodingStandards.html#micro_preincrement 16. In X86RecognizableInsn.cpp, you use the large macro: HANDLE_OPERAND. Could you make it an inlined function instead? It could take a pointer to a member function for...

On Aug 19, 2009, at 4:05 PM, David Greene wrote: > On Wednesday 19 August 2009 18:01, Chris Lattner wrote: > >>> It's not about recovery, it's about message reporting. Right now >>> the LLVM >>> abort messages are formatted completely differently than aborts from >>> other >>> parts of our compiler. That's not friendly to users.

On Wednesday 19 August 2009 18:01, Chris Lattner wrote: > > It's not about recovery, it's about message reporting. Right now > > the LLVM > > abort messages are formatted completely differently than aborts from > > other > > parts of our compiler. That's not friendly to users. > > This is what ErrorReporting.h is all about. But asserts and aborts

Dear mailing list: the attached diff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the

...I used UpgradeIntrinsic* to make them work, since Intrinsic::getDeclaration was changed in an incompatible way too. Are there any other intrinsics that changed? 4. SetCurrentDebugLocation takes a DebugLoc now 5. VISIBILITY_HIDDEN is gone 6. SMDiagnostic takes different parameters 7. APIs renamed: llvm_report_error -> report_fatal_error llvm_install_error_handler -> install_fatal_error_handler llvm::DwarfExceptionHandling -> llvm::JITExceptionHandling 8. disable calls to memory_barrier. this is not correct for SMP but at least its not crashing. I'll probably have more to add to this list once I...

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive