Re: [patch] cse.c: gcc_assertify an "if" statement whose conditionis always false.

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Thu, 27 Jan 2005, Mark Mitchell wrote:
> Kazu Hirata wrote:
> > Hi Mark,
> >
> >
> >>I dunno, I like asserts -- they document the assumption.  But, there's
> >>no point in guarding ggc_assert with ENABLE_CHECKING, as ggc_assert
> >>already is conditionalized on that macro.  OK with that change.
> >
> >
> > Actually, gcc_assert is guarded with ENABLE_ASSERT_CHECKING, not
> > ENABLE_CHECKING.  In other words, if we don't guard this gcc_assert
> > with ENABLE_CHECKING, a release version of GCC would basically have
> >
> >   if (x == 0)
> >     fancy_abort (...);
> >
> > The idea is to keep the assertion while we are developing GCC and omit
> > it when we release it, so I'd like to go with either my original patch
> > or Jakub's idea of droping the whole "if" statement.
> >
> > --enable-checking=release, which will presumably be default on a
> > release, will have ENABLE_ASSERT_CHECKING, but not ENABLE_CHECKING.
>
> I think that was a compromise; people wanted to keep assertions in
> releases for historical reasons.  There's no intrinsic difference
> between a gcc_assert() and something guarded by ENABLE_CHECING.

Oh dear!  No, not historical reasons.  Not at all!  It's because
it's better to abort the compilation than to emit wrong code
when GCC finds an internal inconsistency (with "cheap" tests,
that is).  I'm a bit upset that you think it's just historical.
Maybe I misunderstand what you refer to.

(No, asserts should generally not be guarded by ENABLE_CHECKING.)

brgds, H-P