Re: ICE in change_address at emit_rtl.c

[mike stump <mrs@windriver.com>]

> Date: Fri, 23 Nov 2001 19:14:38 +0000
> From: Neil Booth <neil@daikokuya.demon.co.uk>
> To: Gabriel Dos Reis <gdr@codesourcery.com>

> > | I've not been able to find a satisfactory fix; since I'm not a fan of
> > | error_mark_node-s I don't want to introduce yet more checks for them.
> > | I hate the error_mark_node stuff; it would be nice if it could go
> > | away.
> > 
> > What should be the alternative?

> Generate something that is valid, even if it's not what the user
> specified.

Then you generate a spew of bad messages making gcc substantially
worse from the users perspective, or you in the end rediscover why
error_mark_node exists.  In the end, you can merely replace
error_mark_node with something equivalent, but in the end I can't help
but wonder that you'll have exactly what you started with, just with
all the code shaken up, or something substantially worse.

The theoretics are simple and trivial, for all X, for all OP, nil OP X
--> nil, and X OP nil --> nil.  In our case, nil == error_mark_node.

We hand optimize the checks for nil, opps, I mean, error_mark_node, to
just a few places where they can be (assuming that they don't happen
in other places), which is icky and unmaintainable and what I feel you
are reeling against.  Instead, imagine a language where this check for
nil was part of the language and the user didn't have to write any
code for it, and you will `see' the beauty in the code.  Kinda like
reading the callbacks in C as virtual functions and abstract object
factories and the like, and not being phased by the spelling.
Callbacks in C are ugly to the untrained eye, to a C++ person, a few
specific styles of callbacks are less than gross, even, dare say,
beautiful.

You want it to be better, well, a language upgrade that manages the
code for you (proves where checks for nil need not go, and puts them
everywhere else) would be the best way and then port the code of the
compiler to that system.  By language upgrade, I also would include a
pure library solution to manage the complexity.

> I can only see one good thing they help with: suppression of
> cascading errors.  I can't believe it's too hard to find another way
> of solving that.

It isn't.  error_mark_node does that.  :-) If you can offer a
refinement on the system that appeals to the eye and doesn't kill
compiler performance and preserves the non-cascading nature of
error_mark_node, we are all ears.