search for: report_fatal_error

...ly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { if (auto AddrOrErr = Sym.getAddress()) return *AddrOrErr; else { report_fatal_error(AddrOrErr.takeError()); } } else { report_fatal_error(Sym.takeError()); }}* If the function findSymbol return nullptr, we are executing report_fatal_error and kill everything :( What is the reason for this change? Is this a bug? If this is intended, how can we check from the ExecutionEngine...

.../show_bug.cgi?id=23203 Report of rust bug: https://github.com/rust-lang/rust/issues/26449 Discussion on why Rust doesn't want to fix (a refused patch to libcore): https://github.com/rust-lang/rust/pull/26749 The error is coming from one of these files: lib/Target/X86/X86FastISel.cpp:3166: report_fatal_error("SSE register return with SSE disabled"); lib/Target/X86/X86ISelLowering.cpp:2107: report_fatal_error("SSE register return with SSE disabled"); lib/Target/X86/X86ISelLowering.cpp:2261: report_fatal_error("SSE register return with SSE disabled"); test/CodeGen/...

Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob. Thanks, Filipe F On Fri, Jan 23, 2015 at 2:12 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > The restriction looks reasonable: A record starts with a code. The code > can be encoded as a literal or be p...

...signed"). > For example the fact that clang forks itself to be able to report diagnostics That seems like just trying to make our own job easier to me. I think the entire point of the fork is to get a backtrace we can fix, and point out where the user should send it. > llvm is full of report_fatal_error() (or worse, assertions that can fire on unexpected user input). A bit of a grey area since LLVM isn't itself a user-facing tool, but I think I'd still say that a report_fatal_error that's not actionable by the user is actually an LLVM bug. And a segfault definitely so. Cheers. Tim.

...usage, there are 3 other kinds of errors that are widely used, with the following output styles: Assertion failures: Assertion failed: false && "this is the message", file <filepath> llvm_unreachable failures: this is the message UNREACHABLE executed at <filepath> report_fatal_error failures: LLVM ERROR: this is the message Looking at the existing output, and how they are used, I think llvm_unreachable and assertions do not need standardising, since they are purely for internal usage, whilst report_fatal_error should be standardised to the same as other normal errors (i.e. l...

...elf to be able to report > diagnostics > > > > That seems like just trying to make our own job easier to me. I think > > the entire point of the fork is to get a backtrace we can fix, and > > point out where the user should send it. > > > >> llvm is full of report_fatal_error() (or worse, assertions that can > fire on unexpected user input). > > > > A bit of a grey area since LLVM isn't itself a user-facing tool, but I > > think I'd still say that a report_fatal_error that's not actionable by > > the user is actually an LLVM bug. A...

...setCodeModelForStatic(); For the JIT, this should be setCodeModelForJIT; it makes a difference on, for example, x86-64. I'd also suggest changing the name of the method appropriately. - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + Writer = getBackend().createObjectWriter(OS); + if (!Writer) + report_fatal_error("unable to create object writer!"); + } It would be cleaner if you kept around...

...; > > >> > That seems like just trying to make our own job easier to me. I think > >> > the entire point of the fork is to get a backtrace we can fix, and > >> > point out where the user should send it. > >> > > >> >> llvm is full of report_fatal_error() (or worse, assertions that can > fire on unexpected user input). > >> > > >> > A bit of a grey area since LLVM isn't itself a user-facing tool, but I > >> > think I'd still say that a report_fatal_error that's not actionable by > >> >...

...or the JIT, this should be setCodeModelForJIT; it makes a difference > on, for example, x86-64.  I'd also suggest changing the name of the > method appropriately. > > -  llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); > -  if (!Writer) > -    report_fatal_error("unable to create object writer!"); > +  MCObjectWriter *Writer = Writer_; > +  if (Writer == 0) { > +      Writer = getBackend().createObjectWriter(OS); > +      if (!Writer) > +          report_fatal_error("unable to create object writer!"); > +  } > >...

...(Buffer.getBufferStart()); const unsigned char *EndBufPtr = reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); if (isBitcodeWrapper(BufPtr, EndBufPtr)) { const unsigned char *FixedBufPtr = BufPtr; if (SkipBitcodeWrapperHeader(FixedBufPtr, EndBufPtr, true)) report_fatal_error("Invalid bitcode wrapper"); return EndBufPtr - BufPtr; } if (!isRawBitcode(BufPtr, EndBufPtr)) report_fatal_error("Invalid magic bytes; not a bitcode file?"); BitstreamCursor Reader(Buffer); Reader.Read(32); // skip signature while (true) { size_t EntrySt...

...ks(true); +#else +bool ABICheckDisabled = setABIBreakingChecks(true); +#endif +} +#endif + #endif diff --git a/llvm/lib/Support/Error.cpp b/llvm/lib/Support/Error.cpp index 7436a1fd38ee..151fcdcbfb27 100644 --- a/llvm/lib/Support/Error.cpp +++ b/llvm/lib/Support/Error.cpp @@ -112,3 +112,17 @@ void report_fatal_error(Error Err, bool GenCrashDiag) { } } + + +bool llvm::setABIBreakingChecks(bool Enabled) { + static char abi_breaking_checks_enabled = 0; + static char abi_breaking_checks_disabled = 0; + if (Enabled) + abi_breaking_checks_enabled = 1; + else + abi_breaking_checks_disabled = 1; + if (a...

...f0fa38c2687c65b2bcea5c/), which took the code to read the first argument and put it outside of the loop, but didn't take the Array/Blob verification + reading code too (It's a bug because that commit was supposed to not have changed functionality :-) ). This could be “fixed” with, either a report_fatal_error (if we eventually have better error handling on that code, we can make that non-fatal and report to the caller), or by hoisting the Array/Blob reading code out of the loop too (actually, write a helper function). What should be done about this? Thanks, Filipe -------------- next part ---------...

...+ -void MCAssembler::Finish() { +void MCAssembler::Finish(MCObjectWriter *Writer_) { Why two variables Writer_ and Writer? I don't know of any rules against modifying parameters. ... - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + + llvm::OwningPtr<MCObjectWriter> OwnWriter(0); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + //no custom Writer_ : create the default one life-managed by OwningPtr + OwnWriter.reset(getBackend().createObjectWriter(OS)); +...

...t;> > >>> > That seems like just trying to make our own job easier to me. I think >>> > the entire point of the fork is to get a backtrace we can fix, and >>> > point out where the user should send it. >>> > >>> >> llvm is full of report_fatal_error() (or worse, assertions that can >>> fire on unexpected user input). >>> > >>> > A bit of a grey area since LLVM isn't itself a user-facing tool, but I >>> > think I'd still say that a report_fatal_error that's not actionable by >>>...

...%"atomic::AtomicI16", %"atomic::AtomicI16"* %0, i16 0, i32 0, i32 0 %2 = load atomic i16, i16* %1 seq_cst, align 1 ret void } This trips up the following assertion in CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: if (I.getAlignment() < VT.getSizeInBits() / 8) report_fatal_error("Cannot generate unaligned atomic load"); I've tried commenting out the check and llc finishes, generating not-obviously-wrong machine code, so there doesn't seem to be anything further downstream breaking because of this. So my questions are: * What is the purpose of this a...

...error if a fixup cannot be applied because, for example, the destination of a branch is out of range? I suppose I could use asserts just like AArch64 is doing but that won't stop the assembler of emitting a branch to an undesired location in release builds. Does anyone see any problem in using report_fatal_error to report errors in the target Asm backend ? Regards, Matheus Matheus Almeida MIPS processor IP www.imgtec.com<http://www.imgtec.com/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131203/0be6607c/...

...an important part. > > > My understanding is that clang and llvm themselves are designed this way > (crash when the unexpected happens). For example the fact that clang forks > itself to be able to report diagnostics is a good indication that this is > assumed, and llvm is full of report_fatal_error() (or worse, assertions > that can fire on unexpected user input). > So far as I know, any place where LLVM asserts on user input is a bug - maybe not a high priority bug in some cases, maybe a difficult bug in some cases, but a bug. report_fatal_error is a bit of a wart, to be sure (but th...

...t;> +} >> +#endif >> + >> #endif >> diff --git a/llvm/lib/Support/Error.cpp b/llvm/lib/Support/Error.cpp >> index 7436a1fd38ee..151fcdcbfb27 100644 >> --- a/llvm/lib/Support/Error.cpp >> +++ b/llvm/lib/Support/Error.cpp >> @@ -112,3 +112,17 @@ void report_fatal_error(Error Err, bool GenCrashDiag) { >> } >> >> } >> + >> + >> +bool llvm::setABIBreakingChecks(bool Enabled) { >> + static char abi_breaking_checks_enabled = 0; >> + static char abi_breaking_checks_disabled = 0; >> + if (Enabled) >> + a...

...har *EndBufPtr = >> reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); >> if (isBitcodeWrapper(BufPtr, EndBufPtr)) { >> const unsigned char *FixedBufPtr = BufPtr; >> if (SkipBitcodeWrapperHeader(FixedBufPtr, EndBufPtr, true)) >> report_fatal_error("Invalid bitcode wrapper"); >> return EndBufPtr - BufPtr; >> } >> >> if (!isRawBitcode(BufPtr, EndBufPtr)) >> report_fatal_error("Invalid magic bytes; not a bitcode file?"); >> >> BitstreamCursor Reader(Buffer); >>...

...methods and tablegen). Emitting diagnostics through SourceManager::PrintMessage() "works" in the limited sense of communicating the problem to a human, however it doesn't prevent generation of an incorrect output file or change the process exit code. We'd prefer not to resort to report_fatal_error() since that isn't a polite way to diagnose problems in the source. Is there a sensible way to properly signal a source error from the level of encodeInstruction()? Or is it expected that all such errors are reported earlier?