Re: NDEBUG-like macro

Re: NDEBUG-like macro

[Mike Stump]

I kinda like it...

Re: NDEBUG-like macro

[Jim Wilson]

Since we often compile the first stage of gcc without optimization, such 
checking may not be entirely without cost, depending on how you implement
it.  If you add checks expecting that the optimizer will trivially remove
them, then we may find that bootstrapping takes longer on some platforms.
We also need to be careful that the debugging checks themselves don't
confuse the code to the point of making it harder to debug.  I don't think
either problem is serious though.

Besides checking of trees, we could also do some useful things with RTL
consistency checking between optimization passes.

For instance, it would be nice to have some code that verifies that all
of the REG_DEAD notes are correct.  This would make it easy to find places
that aren't handling them correctly when rewriting insns.  We could also
be consistency checking the reg_n_info variables.

While we are still using obstacks, it might be useful to have code to verify
that all of the RTL for a function is on the right obstack.  This matters
particularly for inline functions that get deferred.

We could be checking for invalidly shared RTL.

Jim

Re: NDEBUG-like macro

[Jeffrey A Law]

  In message <Pine.SOL.3.90.980416103727.7938C-100000@hutch.informatik.rwth-aac
hen.de>you write:
  > The tree and rtl structures are terribly overloaded.
Very true.  Though believe it or not it's a lot better than it used
to be, particularly in the tree structure.

Probably the best thing to come out of the attempt to combine static
variables into a "static block" to reduce address computations was
the cleanups we did to the tree structures.

Due to lameness in obstacks and a need to preserve existing semantics
we had to do a recursive copy of the entire tree structure starting
at each node representing a deferred static variable.

This (of course) sucked up a ton of memory, but it also exposed
things like storing ints into pointers, dangling memory references,
storing rtl in tree nodes, etc etc.    I didn't know much about
trees and how to interpret them before I started -- that all changed
by the end of that project! :-)

jeff

Re: NDEBUG-like macro

[Bernd Schmidt]

On Wed, 15 Apr 1998, Mark Mitchell wrote: 
>   In private email, Jeff and I have been discussing the following
>   proposal:
> 
>   o Add a configuration option --enable-checking to enable additional,
>     possibly costly, consistency checks in the compiler.

>   The motivation for this is the disturbingly common situation in
> which I find that bugs are triggered by using, say, DECL_INITIAL on a
> tree node that is not a DECL.  In general, the use of a macro that
> pulls something out of a tagged union when the tag doesn't match.  It
> would be nice if we could blow up when we did this wrong.

The tree and rtl structures are terribly overloaded. Some of that checking
could be done at compile-time instead of at run-time, by introducing new
types. For example, it might be possible to distinguish between trees that
describe expressions and those that describe types instead of calling both
simply a "tree".
Of course such a change would require a lot more work.

Bernd

Re: NDEBUG-like macro

[Martin von Loewis]

>   So, comment away!

I think this is a very good idea, and should be implemented.

Martin

NDEBUG-like macro

[Mark Mitchell]

Folks --

  In private email, Jeff and I have been discussing the following
  proposal:

  o Add a configuration option --enable-checking to enable additional,
    possibly costly, consistency checks in the compiler.

  o This option would cause the definition of the macro ENABLE_CHECKING
    throughout compilation of the compiler.

  o Then, we could add checks in the compiler that are only enabled
    if ENABLE_CHECKING.

  The motivation for this is the disturbingly common situation in
which I find that bugs are triggered by using, say, DECL_INITIAL on a
tree node that is not a DECL.  In general, the use of a macro that
pulls something out of a tagged union when the tag doesn't match.  It
would be nice if we could blow up when we did this wrong.
Unfortunately, checking this everywhere will be quite costly; so much
so that we should not do it when a normal user is using the compiler.
Hence the need for a compile-time option.

  Jeff said:

> I'm got no particular problem with this, though I'd like to see
> it at least mentioned on the list so that Jim, Jason, etc can
> comment. 

  So, comment away!

-- 
Mark Mitchell <mmitchell@usa.net>
http://home.earthlink.net/~mbmitchell
Consulting Services Available