This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/32074] Optimizer does not exploit assertions
- From: "scovich at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 29 Mar 2012 02:46:50 +0000
- Subject: [Bug middle-end/32074] Optimizer does not exploit assertions
- Auto-submitted: auto-generated
- References: <bug-32074-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
--- Comment #5 from Ryan Johnson <scovich at gmail dot com> 2012-03-29 02:46:50 UTC ---
(In reply to comment #4)
> We have __builtin_unreachable() now which should allow for this optimization.
I've been using __builtin_unreachable() for some time now, and it's very nice
for its intended purpose (telling gcc when it's safe to produce better code).
I've noticed, though, that the ``x'' passed to assert(x) in already-existing
code is often too expensive (or side effect-ful) to optimize away when
converted to ``if(!(x)) { __builtin_unreachable(); }''
I would therefore advise against executing the expression passed to assertions
under NDEBUG. I use the following in my own code instead:
#ifdef NDEBUG
#define ASSUME(x) do { if (!(x)) __builtin_unreachable(); } while (0)
#else
#define ASSUME assert
#endif
The idea is to state assumptions that might help the compiler generate better
code... treating them like assertions in debug mode to catch faulty
assumptions. Assertions, meanwhile, should retain their traditional purpose of
debugging aid or sanity test and continue to disappear completely in NDEBUG
node.
Recommend to close as WONTFIX, unless there are other reasons to keep it open.