search for: llvm_debug_build

...ommend that you take a look, particularly at the config.h change which is still the current 3.5 plan (the llvm_assert changes which make the bulk of the patch aren't in the plan for now though). To summarise, it's a matter of replacing the 5 or so structurally significant NDEBUG with a LLVM_DEBUG_BUILD macro definition in the generated llvm-config.h header. > > While having different components of LLVM and consumers of LLVM able > to intermix NDEBUG and !NDEBUG built code freely without ABI issues is > nice-to-have in my book, the functionality provided by AssertingVH is > sig...

...ull"); But not a fundamentally new thing, etc. (& could be proposed independent of renaming 'assert' to LLVM_ASSERT) > > > If we have custom asserts, then we can have custom assert guard macros: > > > > // true if this is any sort of debug build > > LLVM_DEBUG_BUILD > > > > // true if asserts are turned on (Debug build on Windows, > > // Debug build or -DLLVM_ASSERTIONS_ENABLED=TRUE on other platforms) > > LLVM_ASSERTS_ENABLED > > > > These flags could be derived from just CMAKE_BUILD_TYPE, and > LLVM_ENABLE_ASSERTIONS...

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

On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote: >> Even when you have a !NDEBUG build, the platform assert() is pretty >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes >> just pops up a dialog. WebKit and other projects take the same approach >> and define their own assertion macros to deal with this portably. >>