search for: llvm_unreachable

This patch implements the current consensus of PR8973: http://llvm.org/bugs/show_bug.cgi?id=8973. The macro llvm_unreachable is used in LLVM to indicate that a particular place in a function is not supposed to be reachable during execution. Like an assert macro, it takes a string argument. In +Asserts builds, this string argument, together with some location information, is passed to a function which prints the informa...

...+294,7 @@ static inline bool ProvideOption(Option *Handler, StringRef ArgName, break; default: - errs() << ProgramName - << ": Bad ValueMask flag! CommandLine usage error:" - << Handler->getValueExpectedFlag() << "\n"; - llvm_unreachable(0); + llvm_unreachable("Bad ValueMask flag!"); } and --- a/lib/Support/APInt.cpp +++ b/lib/Support/APInt.cpp @@ -1440,16 +1440,14 @@ APInt APInt::sqrt() const { APInt nextSquare((x_old + 1) * (x_old +1)); if (this->ult(square)) return x_old; - else if (this->ule...

Hi John, > This patch implements the current consensus of PR8973: > http://llvm.org/bugs/show_bug.cgi?id=8973. > > The macro llvm_unreachable is used in LLVM to indicate that > a particular place in a function is not supposed to be reachable > during execution. Like an assert macro, it takes a string > argument. In +Asserts builds, this string argument, together with > some location information, is passed to a function which...

On 12.03.2011, at 11:17, Duncan Sands wrote: > Hi John, > >> This patch implements the current consensus of PR8973: >> http://llvm.org/bugs/show_bug.cgi?id=8973. >> >> The macro llvm_unreachable is used in LLVM to indicate that >> a particular place in a function is not supposed to be reachable >> during execution. Like an assert macro, it takes a string >> argument. In +Asserts builds, this string argument, together with >> some location information, is passed to a...

...ption(Option *Handler, > StringRef ArgName, > break; > > default: > - errs() << ProgramName > - << ": Bad ValueMask flag! CommandLine usage error:" > - << Handler->getValueExpectedFlag() << "\n"; > - llvm_unreachable(0); > + llvm_unreachable("Bad ValueMask flag!"); This patch would lose the expected flag value, which is unfortunate. > +++ b/lib/Support/APInt.cpp > @@ -1440,16 +1440,14 @@ APInt APInt::sqrt() const { > APInt nextSquare((x_old + 1) * (x_old +1)); > if (this->ul...

This patch implements the current consensus of PR8973: http://llvm.org/bugs/show_bug.cgi?id=8973. The macro llvm_unreachable is used in LLVM to indicate that a particular place in a function is not supposed to be reachable during execution. Like an assert macro, it takes a string argument. In +Asserts builds, this string argument, together with some location information, is passed to a function which prints the informa...

...ement to what we can effectively express to help the compiler optimize more effectively. Thanks for doing this. -Jim On Mar 11, 2011, at 6:55 PM, John McCall wrote: > This patch implements the current consensus of PR8973: > http://llvm.org/bugs/show_bug.cgi?id=8973. > > The macro llvm_unreachable is used in LLVM to indicate that > a particular place in a function is not supposed to be reachable > during execution. Like an assert macro, it takes a string > argument. In +Asserts builds, this string argument, together with > some location information, is passed to a function whic...

Hi Sebastian, >>> This patch implements the current consensus of PR8973: >>> http://llvm.org/bugs/show_bug.cgi?id=8973. >>> >>> The macro llvm_unreachable is used in LLVM to indicate that >>> a particular place in a function is not supposed to be reachable >>> during execution. Like an assert macro, it takes a string >>> argument. In +Asserts builds, this string argument, together with >>> some location information...

...StringRef ArgName, >>     break; >> >>   default: >> -    errs() << ProgramName >> -         << ": Bad ValueMask flag! CommandLine usage error:" >> -         << Handler->getValueExpectedFlag() << "\n"; >> -    llvm_unreachable(0); >> +    llvm_unreachable("Bad ValueMask flag!"); > > This patch would lose the expected flag value, which is unfortunate. It is unfortunate - though I'm not sure whether you're suggesting that the change should be made anyway, or not. I'd say the whole unreac...

...would you prefer to see? As well as "regular" errors you'll see in typical 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,...

Hi all, Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think there’s definitely room for some heuristics around ignoring things like llvm_unreachable (perhap...

+ cfe-dev > On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. FWIW, Daniel Dunbar and a few others have brought up the lack of a flexible "suppress coverage" mechanism as a pain-point. There are two separate but related solution...

On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: > For a bit of an experiment I've been trying to compile LLVM & Clang > with -Weverything (disabling any errors that seem like more noise/less > interesting). One warning I've recently hit a few instances of is > -Wweak-vtable which is, in fact, an explicitly documented LLVM coding > standard (

...gt; break; >>> >>> default: >>> - errs() << ProgramName >>> - << ": Bad ValueMask flag! CommandLine usage error:" >>> - << Handler->getValueExpectedFlag() << "\n"; >>> - llvm_unreachable(0); >>> + llvm_unreachable("Bad ValueMask flag!"); >> >> This patch would lose the expected flag value, which is unfortunate. > > It is unfortunate - though I'm not sure whether you're suggesting that > the change should be made anyway, or not. &...

...ol alignment of code. We have not come to an agreement as a community on the best way forward here. This flang-dev thread<http://lists.llvm.org/pipermail/flang-dev/2020-March/000243.html> summarises the debate. We would like to continue this debate after F18 becomes part of the monorepo. [2] llvm_unreachable Previously we stated that we would try to use llvm_unreachable in F18 whenever possible. Presently, F18 has a similar function called die, but this is used to cover multiple run-time error cases only some of which should be covered by llvm_unreachable. We would like to handle all cases together whi...

For a bit of an experiment I've been trying to compile LLVM & Clang with -Weverything (disabling any errors that seem like more noise/less interesting). One warning I've recently hit a few instances of is -Wweak-vtable which is, in fact, an explicitly documented LLVM coding standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch ). Some instances of this have been easy to

...lled in the epilogue, then we can use BL to implement a far jump. /// Otherwise, add an intermediate branch instruction to a branch. bool ARMConstantIslands::fixupUnconditionalBr(ImmBranch &Br) { MachineInstr *MI = Br.MI; MachineBasicBlock *MBB = MI->getParent(); if (!isThumb1) llvm_unreachable("fixupUnconditionalBr is Thumb1 only!"); // Use BL to implement far jump. Br.MaxDisp = (1 << 21) * 2; MI->setDesc(TII->get(ARM::tBfar)); BBInfo[MBB->getNumber()].Size += 2; adjustBBOffsetsAfter(MBB); HasFarJump = true; ++NumUBrFixed; DEBUG(dbgs() &...

...ol alignment of code. We have not come to an agreement as a community on the best way forward here. This flang-dev thread<http://lists.llvm.org/pipermail/flang-dev/2020-March/000243.html> summarises the debate. We would like to continue this debate after F18 becomes part of the monorepo. [2] llvm_unreachable Previously we stated that we would try to use llvm_unreachable in F18 whenever possible. Presently, F18 has a similar function called die, but this is used to cover multiple run-time error cases only some of which should be covered by llvm_unreachable. We would like to handle all cases together whi...

I have a question about MCExpr and its subclasses defined in MCExpr.h. I am trying to get Mips' direct object emission working. Line 283 of MCElfStreamer.cpp reads like this: 00283 case MCExpr::Target: llvm_unreachable("Can't handle target exprs yet!"); Does this mean that if I use a subclass of MCTargetExpr to lower MachineOperands to MCOperands, it won't work? Currently, symbol operands are lowered to MipsMCSymbolRefExpr (a subclass of MCTargetExpr) objects.

...o an agreement as a community on the best way forward here. > This flang-dev thread > <http://lists.llvm.org/pipermail/flang-dev/2020-March/000243.html> > summarises the debate. We would like to continue this debate after F18 > becomes part of the monorepo. > > > > [2] llvm_unreachable > > Previously we stated that we would try to use llvm_unreachable in F18 > whenever possible. Presently, F18 has a similar function called die, but > this is used to cover multiple run-time error cases only some of which > should be covered by llvm_unreachable. We would like to hand...