similar to: [LLVMdev] [patch] Change llvm_unreachable to use __builtin_unreachable() in -asserts

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

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 >

Such an awesome change it was worth saying twice! :) Sounds great, and I completely agree it's a nice enhancement 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. >

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

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

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 (perhaps opt-in?). I’m

+ 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

On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: > 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 >>

On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >> 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).

On Thu, Dec 1, 2011 at 9:11 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 12:08 AM, David Blaikie wrote: > >> On Wed, Nov 30, 2011 at 10:42 PM, Chris Lattner <clattner at apple.com> wrote: >>> 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

I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) 1) VFP/Neon instructions don't encode correctly at al, because the encoding methods generated by tablegen for them

Hi all, This came up in a recent review. There is currently no documented style for how to write error messages. For example, should they start with a capital letter or end in a full stop? Consequently, there's quite a bit of inconsistency in our diagnostics throughout the code base. clang typically emits error messages with no leading capital letter and no trailing full stop. For example:

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

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 Aug 19, 2009, at 7:29 PM, Óscar Fuentes wrote: Eli Friedman <eli.friedman at gmail.com> writes: > Besides, in my experience all LLVM asserts I see are Type mismatches > for > instructions and similar cases, i.e., errors about my compiler > producing > wrong LLVM "code" through the API, plus some occasional bug on LLVM, > sometimes about one layer passing

Hi llvm-dev We believe we have completed enough of the agreed pre-upstreaming changes to start talking about merging F18 into LLVM. The live status is tracked at [1]. There are a few details that we have not managed to hammer out and we propose to tackle inside the LLVM monorepo. I have put a summary of these at the bottom of this mail. Does anyone have any objections to flang being merged into

Craig, On Aug 30, 2011, at 12:51 PM, Craig Smith wrote: > I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. > I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) The non-MC-based ARM JIT path is known not to work,

On Aug 30, 2011, at 3:12 PM, Owen Anderson wrote: > The non-MC-based ARM JIT path is known not to work, and nobody is working on fixing it. The MC-based instruction encoder is rapidly maturing is generally passable for static encoding, but the MCJIT is still in its infancy. I was relying on this support in LLVM 2.8, and while it is definitely incomplete, it does work if you don't depend

Hi Sean, > 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

I don't know ARM hardly at all but... This comment does not seem to match the code. Or maybe tBfar is a BL? Also, how does this work if the destination is greater than 2**21? /// fixupUnconditionalBr - Fix up an unconditional branch whose destination is /// too far away to fit in its displacement field. If the LR register has been /// spilled in the epilogue, then we can use BL to