similar to: [LLVMdev] Proposal for better assertions in LLVM

On Tue, Jul 26, 2011 at 10:41 AM, Talin <viridia at gmail.com> wrote: > The assertions in LLVM would be a lot more useful if they could print out > not only the source code of the expression that failed, but also print the > values of the various arguments. To that end, I have an idea for an improved > assert macro which would use raw_ostream. It would look something like this:

On Wed, Jul 27, 2011 at 12:51 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Jul 26, 2011 at 10:41 AM, Talin <viridia at gmail.com> wrote: > >> The assertions in LLVM would be a lot more useful if they could print out >> not only the source code of the expression that failed, but also print the >> values of the various arguments. To that end, I

On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com> wrote: > #define ASSERT_STRM(cond, args) \ >> if (!(cond)) AssertionFailureStream(__FILE_**_, __LINE__) << args >> >> Note that there's no trailing semicolon, as this is supplied at the >> point where the macro is invoked. >> >> What do you think? >> >

> #define ASSERT_STRM(cond, args) \ > if (!(cond)) AssertionFailureStream(__FILE__, __LINE__) << args > > Note that there's no trailing semicolon, as this is supplied at the > point where the macro is invoked. > > What do you think? Neat, but inducing a debug trap is even more useful on asserts (optionally).

Den 26.07.2011 20:12, skrev Talin: > On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com > <mailto:flylanguage at gmail.com>> wrote: > > #define ASSERT_STRM(cond, args) \ > if (!(cond)) AssertionFailureStream(__FILE____, __LINE__) > << args > > Note that there's no trailing semicolon, as this

On Jul 26, 2011, at 9:17 PM, Talin wrote: > Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: > > assert(C->getType() == T->getElementType() && > "Initializer for vector element doesn't match vector element type!"); > > I would change this to: > >

Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: assert(C->getType() == T->getElementType() && "Initializer for vector element doesn't match vector element type!"); I would change this to: ASSERT_STRM(C->getType() == T->getElementType(), "Initializer for vector element "

wrapping the macro's body in: do { ... } while (false) would make the the macro a proper statement so that: if (cond) ASSERT(some_other_cond); else do_something_cool (); compiles as expected. IMO, it would work as such #define ASSERT_STM(cond,expr) On Tue, Jul 26, 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > He wants to be able to resume execution

sorry, my previous message got sent too early I think the macro should look something like this: #define ASSERT_STRM(cond,expr) \ do { if (cond) { std::cerr << expr << std::end; assertion_trap (); } } while (false) On Tue, Jul 26, 2011 at 7:57 PM, Nathan Jeffords <blunted2night at gmail.com>wrote: > wrapping the macro's body in: > > do { ... } while

By the way, abort() trips the debugger as well - at least, it does in gdb. On Tue, Jul 26, 2011 at 12:12 PM, FlyLanguage <flylanguage at gmail.com> wrote: > Den 26.07.2011 20:12, skrev Talin: > >> On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com >> <mailto:flylanguage at gmail.com>**> wrote: >> >> #define

Great suggestion - what should the !NDEBUG version look like? On Tue, Jul 26, 2011 at 8:01 PM, Nathan Jeffords <blunted2night at gmail.com>wrote: > sorry, my previous message got sent too early > > I think the macro should look something like this: > > #define ASSERT_STRM(cond,expr) \ > do { > if (cond) { > std::cerr << expr << std::end; >

On Wed, Jul 27, 2011 at 3:31 PM, Talin <viridia at gmail.com> wrote: > Can you explain how it avoids evaluating the arguments in the false case? I > looked at the code but it's pretty complex. > Essentially it expands to something like: !(Ty == STy) ? (void)0 : Voidifier() & llvm::dbgs() << ... where you have something vaguely along the lines of struct Voidifier {

On Tue, Jul 26, 2011 at 10:59 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 9:17 PM, Talin wrote: > > Here's an example of how this would be used: In the constructor for > ConstantVector, there's an assert: > > assert(C->getType() == T->getElementType() && > "Initializer for vector element doesn't

Please review this patch for PR3510 (and <rdar://problem/6564697>). The bug is a failure to handle a "hole" inside an initialized structure, where the hole may be induced by a designated initializer or by alignment: http://llvm.org/bugs/show_bug.cgi?id=3510 The original code was greatly simplified by using FieldNo to index the LLVM fields and the initializer in

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

On Jul 27, 2011, at 12:41 AM, Talin wrote: > What do you mean "the linker fails"? Type mismatches should not cause the linker to fail. In any case, this example should link, please provide a minimal example of two .ll files that repros what you're seeing with llvm-link. Thanks, > > It's llvm-ld that asserts here: > > Assertion failed: (N < NumContainedTys

On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 8:11 AM, Talin wrote: > > >> If that's true, then it means that we're back to the case where every type >> has to be fully defined down to the leaf level. >> >> >> I'm not sure what you mean. LLVM is perfectly fine with opaque structs

This is for BPF output. BPF program output bytes to perf through a tracepoint. For decoding such data, we need a way to describe the format of the buffer. This patch is a try which gives each variable a unique number by introducing a new intrinsic 'llvm.typeid.for'. At the bottom is an example of using that intrinsic and the result of $ clang -target bpf -O2 -c -S ./test_typeid.c

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into