Re: enable-checking: error_mark accessed as type

[Jason Merrill <jason at cygnus dot com>]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> I especially have a problem with creating ERROR_MARK nodes that
 >> are not error_mark_node.
 >> 
 >> Basically, I think we need a cleaner solution to this problem.  How does
 >> the C frontend deal with this issue?

 > I assume they don't have such problems.

No, grokdeclarator puts error_mark_node into TREE_TYPE of decls in C, too.

 > The specific problem with build_dummy_object is that it is passed to
 > integer_zerop. That could be solved by extending STRIP_NOP to expect
 > error_mark_node, or by not putting ERROR_MARKs into your dummy objects.

 > I don't understand why the dummy object *has* to have an
 > error_mark_node inside, it seems any recognizable pattern would do.

Yes, so long as it can't get there normally.  How about using
void_zero_node instead?

 > Other than that, my patch does not produce new ERROR_MARKs. As for
 > checking for both error_mark and error_type: Based on the current test
 > suite, this only rarely has to be done.  If we put an error_mark into a
 > type, we *already* printed an error message. The code just has to get
 > through somehow, for error stabilization.

Yep; that's what it means other places, too.  I'd rather just fix the
places that don't currently check for TREE_TYPE == error_mark_node.  Mark,
do you have any input?

Jason