Re: [patch] tree-cfg.c: Speed up cleanup_tree_cfg().

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2004-10-01 at 13:44, Jakub Jelinek wrote:
> On Fri, Oct 01, 2004 at 01:39:20PM -0400, Andrew MacLeod wrote:
> > > That's exactly what Kazu's patch does:
> > > 
> > > + #ifdef ENABLE_CHECKING
> > > +   if (retval)
> > > +     gcc_assert (!cleanup_control_flow ());
> > > + #endif
> > > 
> > 
> > So gcc_assert() isn't a direct replacement for ENABLE_CHECKING? I was
> > under the impression that the contents of the gcc_assert went away when
> > you disabled checking...
> > 
> >   gcc_assert (cond);
> > becomes
> >   0 && cond;
> > or some such thing.
> > 
> > Is this not true sometimes?
> 
> Whether gcc_assert expands to 0 && cond or actual checking and assertion
> failure depends on what exact checking was requested.
> E.g. for GCC 4.0 release, I believe the default will be
> --enable-checking=release, i.e. gcc_assert will be checked at runtime
> and abort, while ENABLE_CHECKING will not be set.
> Thus, gcc_assert not guarded by ENABLE_* macros should be only used
> if the test is really cheap.
> Also, gcc_assert should never be used if the test has side-effects
> which might influence compiler output.
> 

Interesting. Thats not the way I understood it, and I suspect I am not
the only one. (Or maybe I just didn't pay enough attention :-|)   I was
under the impression we just replaced all our #ifdef ENABLE_CHECKING 
tests with gcc_assert(), and they were going to go away in non-checking
compilers. nice, clean, and simple.

I'm willing to bet there are places where we slow down a release
compiler because we are performing a lot of assertions  we thought we
were only doing with ENABLE_CHECKING. I certainly have written some.
bah.

Andrew