search for: llvm_enable_asserts

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 Thu, Apr 9, 2020 at 9:59 AM Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David, > > > > In my opinion, NDEBUG is one of those gross old C things that everybody > complains about. It’s called “Not Debug”, but really it means “Assert > Disabled”. I think one could be forgiven for actually using it as a > heuristic of whether or not a build

...lf a >> "Release-Asserts build" while all asserts are thrown away, hmmm :) > > Yeah, that's "Release-Asserts" as in "Release minus asserts". > > This has caused confusion before... Committed a change for the cmake build that implements the option LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is Release. -- Óscar

Hi, > Committed a change for the cmake build that implements the option > LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is > Release. Thanks! I think it might be nice to make this a bit more consistent with Makefile.config. I'd suggest... - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS - have it default to OFF (so assertions are enabled) always -...

Jay Foad <jay.foad at gmail.com> writes: >> Committed a change for the cmake build that implements the option >> LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is >> Release. > > Thanks! I think it might be nice to make this a bit more consistent > with Makefile.config. I'd suggest... > > - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS Okay. > - have it default to O...

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,

Hi, While audit our code, we found out a strange pattern in one of the LLVM headers and we were wondering if that was expected or if it should be fixed. Namely the problem looks like this: #ifndef NDEBUG // Define some variable. #endif assert(/*use this variable, i.e., outside of the ifndef NDEBUG scope*/); This happens in include/llvm/IR/ValueHandle.h for the variable Poisoned line 494

Hi, I have having hard time to let cmake configuration detect the zlib header in windows with "Visual Studio 12" generator. My cmake configuration goes like >> Set path, include and lib environment variables to point to zlib headers and libraries. Cmake version is 2.8.12.2 cmake -G "Visual Studio 12" -D LLVM_TARGETS_TO_BUILD:STRING=%TARG% -D

>> Thanks! I think it might be nice to make this a bit more consistent >> with Makefile.config. I'd suggest... >> >> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS > > Okay. I meant ...DISABLE... instead of ...ENABLE...! >> I don't think -UNDEBUG has any effect, because NDEBUG won't have been >> defined in the first place > > Right. For Release builds, cmake automatically defines NDEBUG. OK, I didn't know that! Thanks,...

On 2020-04-10, Michael Kruse via llvm-dev wrote: >#ifndef NDEBUG in the LLVM source and assert() are at least somewhat >linked. For instance, consider >https://github.com/llvm/llvm-project/blob/8423a6f36386aabced2a367c0ea53487901d31ca/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp#L2668 > >The #ifndef NDEBUG is used to guard the value that checked in an >assert() later. Only

Hi Skykill, > Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s > the same with 3.0) for running a bitcode on a C++ program, and Clang for > compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m > on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested > in both Release and Debug build). Project was make

Good point, I forgot to check the standard. Given the clang was failing I assumed the code was wrong x). I am guessing there is something weird with the project, because indeed, paragraph 7.2 of the standard says: The assert macro is redefined according to the current state of NDEBUG each time that <assert.h> is included. > On Oct 4, 2017, at 2:53 PM, Craig Topper <craig.topper at

On Wed, Aug 27, 2014 at 4:29 PM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > prefix = CMAKE_INSTALL_PREFIX > enabled-shared = BUILD_SHARED_LIBS > targets = LLVM_TARGETS_TO_BUILD (defaults to all, or use a semicolon separated list) > disable-assertions = LLVM_ENABLE_ASSERTIONS (obviously inverted ;) > > I don't

Hi, so yes assertions are enabled by default in Debug from what i could see in the CMakeLists.txt if( uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE" ) option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) else() option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) endif() Without assertions enabled, when i'm running the program without the debugger, it

I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \

>> I am happy to start writing a patch for the documentation > > Thanks. Please Cc me for review. Will do. >> # LLVM_BUILD_* values available only from LLVM build tree. > > Those were created to simplify building Clang locally against a > LLVM build tree. Clang needs the LLVM source and build trees too, > so this gives it that information. No information is

On Sat, Oct 14, 2017 at 4:22 PM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > The only way I could reproduce the problem you are seeing was to rerun > cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously > configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure > if it's what you are seeing. > > If this isn't your

Paul Melis wrote: > Just checked: yup, there's plenty of assert()'s in the headers, so > -D_DEBUG will keep those alive. > > Interestingly, when configuring with --enable-optimized and > --disable-assertions the resulting compilation calls itself a > "Release-Asserts build" while all asserts are thrown away, hmmm :) Yeah, that's "Release-Asserts"

Jay Foad <jay.foad at gmail.com> writes: >>> Thanks! I think it might be nice to make this a bit more consistent >>> with Makefile.config. I'd suggest... >>> >>> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS >> >> Okay. > > I meant ...DISABLE... instead of ...ENABLE...! The `configure' script accepts --enable-x and --disable-x. CMake uses -DX=ON and -DX=OFF. For consistency, I chose to follow the naming scheme LLVM_ENABLE_X for all the switches supported by the cmake build. [sni...