[patch] cse.c: gcc_assertify an "if" statement whose condition is always false.

[Jeffrey A Law]

On Thu, 2005-01-27 at 11:40 -0800, 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.
> 
> In any case, I think that guarding asserts with ENABLE_CHECKING is 
> weird; if you want to guard it with ENABLE_CHECING, then don't use 
> ggc_assert.
> 
> What do other people think?
Well, I definitely prefer having the assert vs just removing the code
as Jakub suggested.

The assert states pretty clearly that if we get into this code with
x == 0 that the problem lies elsewhere -- ie, if the caller might
pass in a null value, then the caller is at fault.

As to whether or not we wrap the assert into an ENABLE_CHECKING or
not.  I don't really care, particularly since 99.9% of my builds
are with checking-enabled compilers.

jeff