similar to: [PATCH 1/2] Fix assert when NDEBUG defined

See http://gcc.gnu.org/gcc-4.3/porting_to.html for details. Signed-off-by: Jon Ringle <jon at ringle.org> --- usr/include/klibc/compiler.h | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/usr/include/klibc/compiler.h b/usr/include/klibc/compiler.h index 816a4ee..e0da37e 100644 --- a/usr/include/klibc/compiler.h +++ b/usr/include/klibc/compiler.h @@ -24,7 +24,11

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

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

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

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

Hi Mr/Mz, I have built and installed llvm-2.8 in debug mode using: >SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized --enable-debug-symbols >make install It seems the NDEBUG controls a lot of print-out of debug information, by using DEBUG() or dbgs(). And it is said that NDEBUG is in enabled in debug mode, but I find it does not work and the -debug option

with the recent move of the includes from linux' include/asm-$ARCH to arch/$ARCH/asm, klibc fails to compile, because the in-linux-header files include from asm/, but this is not in the header search path. e.g. against linux-2.6.27 arm: arm-iwmmx-linux-gnueabi-gcc -Wp,-MD,usr/klibc/.vsnprintf.o.d -nostdinc -iwithprefix include -Iusr/include/arch/arm -Iusr/include/bits32

On Tue, Jul 07, 2020 at 09:51:53AM -0500, Eric Blake wrote: > While we support compilation with CFLAGS=-DNDEBUG for the brave user > desiring to avoid assertion overhead, this causes the tests to be less > powerful. Fortunately, a quick test of './configure CFLAGS=-DNDEBUG' > didn't hit any test failures, but it seems better to just ensure that > assertions always work

Hi everyone, we have several header files in which the NDEBUG macro is being used. In some of these, the NDEBUG macro changes the size, the interface, or the layout of a type. One example is AssertingVH, which turns into a flat, transparent Value* wrapper in Release build. Now everywhere you use these headers, the state of the NDEBUG flag must be the same, or else bad things could happen. This

Hi Li Qingan, > Thanks for your last reply. > I have made a critical mistake when I stated my question in last email. > I built llvm in debug mode, but the NDEBUG seemed to be still defined, such that > the -debug option is not enabled. > I have restated my configuration below. you need to configure with --enable-assertions In spite of the name, NDEBUG is not related to

While we support compilation with CFLAGS=-DNDEBUG for the brave user desiring to avoid assertion overhead, this causes the tests to be less powerful. Fortunately, a quick test of './configure CFLAGS=-DNDEBUG' didn't hit any test failures, but it seems better to just ensure that assertions always work in our tests, even if they are turned off for the main binary. Signed-off-by: Eric

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

Following example from usr/include/arch/i386/klibc/archsignal.h: The in-kernel headers for arm still have libc5 crap in them. Reconsider using <asm/signal.h> when/if it gets cleaned up; for now, duplicate the definitions here. Signed-off-by: Jon Ringle <jon at ringle.org> --- usr/include/arch/arm/klibc/archsignal.h | 112 ++++++++++++++++++++++++++++++- 1 files changed, 110

I always use --prefix, and it gets put in the right place (<prefix>/include/FLAC/assert.h), which I'm sure sheds no new light on this. I'd still like to know why FLAC__ASSERT() is necessary. K&R is very clear that the preprocessor is to remove calls to assert() if NDEBUG is defined. (Some compilers, including gcc, implicitly define NDEBUG when optimizing, but of course it can

Use headers_install to install headers. arch include directory has moved and it's better to ask the kernel Makefile to install the headers for us. Signed-off-by: Jon Ringle <jon at ringle.org> --- scripts/Kbuild.install | 11 +---------- 1 files changed, 1 insertions(+), 10 deletions(-) diff --git a/scripts/Kbuild.install b/scripts/Kbuild.install index 44c8f76..de918f0 100644 ---

--- usr/include/signal.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/usr/include/signal.h b/usr/include/signal.h index a513282..4ed65bc 100644 --- a/usr/include/signal.h +++ b/usr/include/signal.h @@ -44,10 +44,12 @@ typedef int sig_atomic_t; /* The kernel header files are inconsistent whether or not SIGRTMAX is inclusive or exclusive. POSIX seems to state that

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 19 +------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124 ++++++++++++++++++++++++++++++++++++++++++

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 52 ++++++++++++------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124

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,