This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]