search for: llvm_assert

...tool, so it's not a big hassle to keep this up to date until >>> 3.4 is out the door. >>> >>> A handful of fixes were needed to add support for Release+Assert >>> builds and these are also separate commits. >> Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The >> use of assert in header files is not a problem for "libraries", it is >> things like: >> >> #ifndef NDEBUG >> int SomeNewVariable; >> #endif > They're both are a problem. assert() is defined deep down in the C > library head...

...;> internal tool, so it's not a big hassle to keep this up to date until >> 3.4 is out the door. >> >> A handful of fixes were needed to add support for Release+Assert >> builds and these are also separate commits. > > Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The > use of assert in header files is not a problem for "libraries", it is > things like: > > #ifndef NDEBUG > int SomeNewVariable; > #endif They're both are a problem. assert() is defined deep down in the C library headers and is conditional on !NDEBUG...

...fixes were needed to add support for Release+Assert builds and these are also separate commits. TableGen and internal tools continue to use ordinary platform assert() / NDEBUG (I think a few uses might have been incorrectly changed, will check over), as do the C++ sources and non-public headers. llvm_assert() is a bit more verbose but it actually fits into the coding style well, and it's grown on me. Extract from README.txt: |This patchset against LLVM r194356 implements API stability.|| || ||Embedding is now fully independent of build configuration, with the exception of C++11 feature checks in...

...rt, it is intrinsically tied to NDEBUG. What we need > is proper custom asserts. In codebases I’ve seen in my travels that have > this it usually looks like: > > > > // If asserts are enabled, evaluate and assert that expr is truthy. If it > is not, complain with msg. > > LLVM_ASSERT(expr, msg) > > > > // If asserts are enabled, evaluate and assert that expr is truthy. If it > is not, complain with msg. > > // If asserts are disabled, evaluate expr, do not assert. > > // either way, return expr > > LLVM_VERIFY(expr, msg) > > > > T...

...>> So as far as I can tell, as long as the headers use assert(), > they need > >> to use our own version in order for the definition to match. > > > > Chris, > > > > Having said that, I agree it's worth trying without > llvm_assert() to see > > how far it gets. > > > > I'll pull together a rework of this patchset with just the build > system > > and structure changes alone to see how far it gets. > > > > The key thing then is to make sure that it's saf...

...e process on an assert. Ideally we should be able to implement so set of options where an assert can cause one of a number of error mechanisms to be used from SIGABT to throwing and execption object containing line number file and the error message. This would require replacing asserts with say an llvm_assert( bool, char*) style preprocessor call that can generate the desired response, throw an error to be catched by a handler or doing a C++ throw, depending on how it is defined. I was intending to look into this after implementing the COFF Writer. It should not be too much work to convert the asserts...

...heir own assertion macros to deal with this portably. >> >> So as far as I can tell, as long as the headers use assert(), they need >> to use our own version in order for the definition to match. > > Chris, > > Having said that, I agree it's worth trying without llvm_assert() to see > how far it gets. > > I'll pull together a rework of this patchset with just the build system > and structure changes alone to see how far it gets. > > The key thing then is to make sure that it's safe to enable the > assertions in the headers if an applicat...

...ask: what is the point of llvm_unreachable? Why not just >> use assert? > > assert completely disappears in release builds, often leading to compiler warnings when the compiler thinks a control path doesn't return a value. if the point is to have a better assert, why not introduce llvm_assert and do a bulk replace of all asserts with it? By the way, GCC does this: #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #e...

...and noted. They were refactored with an internal tool, so it's not a big hassle to keep this up to date until 3.4 is out the door. > > A handful of fixes were needed to add support for Release+Assert builds and these are also separate commits. Whoa whoa whoa. Why are you introducing an llvm_assert() macro? The use of assert in header files is not a problem for "libraries", it is things like: #ifndef NDEBUG int SomeNewVariable; #endif in a class. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev...

Chris Lattner <clattner at apple.com> writes: >>>> 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

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

I don't think NDEBUG is that easy. We use assert liberally[1] in templated code in headers. What about cast<>, which has assert(isa<...>...)? On ELF, you have an ODR problem, and you'll get either one or the other based on the whims of the dynamic linker. You could probably get things to the point that it sort of works, but I don't think we could support it without

Hi all, During discussions about assertions in the Flang project, we noticed that there are a lot of cases in LLVM that #ifndef NDEBUG is used as a guard for non-assert code that we want enabled in debug builds. This works fine on its own, however it affects the behaviour of LLVM_ENABLE_ASSERTIONS; since NDEBUG controls whether assertions are enabled or not, a lot of debug code gets enabled in

With the recent thread on using C++11 in LLVM/clang, one of the recurring themes was a desire to make the internal headers more consumable. While I don't personally want any kind of stability guarantee for internal headers, I do think we can do more to ensure that any given snapshot of the headers is consumable from different compilers and build configurations. In practice this means

2013/11/10 Alp Toker <alp at nuanti.com>: > #ifndef NDEBUG > > This is the biggest violation. NDEBUG should only ever be used in source > files. That way if something is crashing we can swap in a debug build > without rebuilding every single dependent application. Win! I wish; - NDEBUG may not modify API. class structure (member offset, vtables) should be stable and

...raw_ostream.h" namespace llvm { // This just writes out "Assertion Failed" and the file/line number in // a form that IDEs can parse. void assertion_prologue(const char * file, unsigned line); // This does the trap or abort or whatever. void assertion_trap(); #if NDEBUG #define LLVM_ASSERT_STRM(expr, args) do {} while false // Alternatively // #define LLVM_ASSERT_STRM(expr, args) (void)0 #else /// Assertion macro that acts as an error output stream. Typical usage: /// /// LLVM_ASSERT_STRM(a != b, "Expected " << a << " == " << "...

...hift /// of any size. bool DAGTypeLegalizer:: ExpandShiftWithUnknownAmountBit(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Amt = N->getOperand(1); MVT NVT = TLI.getTypeToTransformTo(N->getValueType(0)); MVT ShTy = Amt.getValueType(); unsigned NVTBits = NVT.getSizeInBits(); LLVM_ASSERT(isPowerOf2_32(NVTBits) && "Expanded integer type size not a power of two!"); DebugLoc dl = N->getDebugLoc(); // Get the incoming operand to be shifted. SDValue InL, InH; GetExpandedInteger(N->getOperand(0), InL, InH); SDValue NVBitsNode = DAG.getConstant...

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

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