This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: __assert_fail should not be __attribute__((__noreturn__))
- From: Bruno Haible <bruno at clisp dot org>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Johannes Sixt <johannes dot sixt at telecom dot at>, Ulrich Drepper <drepper at redhat dot com>, libc-alpha at sources dot redhat dot com
- Date: Thu, 22 Apr 2004 21:08:09 +0200
- Subject: Re: __assert_fail should not be __attribute__((__noreturn__))
Richard Henderson wrote:
> Actually, the most important thing is that GCC can prove that the
> assert condition is false after the assertion. This knowledge gets
> propagated into following statements.
Yes, it does, but with two major limitations:
1) As Johannes Sixt mentioned, when NDEBUG is used, glibc's assert()
expansion does not contain the condition, therefore the compiler
cannot optimize anything since it doesn't see the condition.
Also there is no way to tell the compiler "this condition is true,
you don't need to evaluate it, you can just assume it is true".
A special built-in, say, __builtin_assert_without_verification(condition),
could do this, no?
2) The information propagation in the compiler is quite limited. It cannot
even deduce that if x >= 10, then also x >= 5: In the following snippet
gcc doesn't eliminate the second test for x, regardless of the NDEBUG
setting.
#include <assert.h>
int foo (int x, int *p) {
assert (x >= 10);
return (x >= 5 ? p[1] : 3*p[0]);
}
Bruno