Re: ICE in change_address at emit_rtl.c

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Joseph S. Myers wrote:-

> On Fri, 23 Nov 2001, Neil Booth wrote:
> 
> > Hmm, OK, if you think it's possible too then it probably is.  I might
> > have a stab at gradually removing it from the C and ObjC front ends
> > after 3.1 has branched; it's not worth it now.  Does that seem a
> > reasonable goal to you Joseph?
> 
> What of the other idea that has been discussed in the past, of typed error
> marks (separate ones for erroneous types, erroneous decls, ...)?

Ugh, no, I want to get rid of them completely, not to add more.  They
just get in the way, and make obviously correct subroutines possibly
incorrect.

> We should first define the goals:
> 
> * How much do we want to help users by finding multiple errors in a single
> compilation run (the point of not just stopping after the first error)?

As much as reasonably possible.  I don't see that removing error marks
affects this (indeed, I think it might even improve it, since things
that might have been error marks before might now be something
sensible, maybe finding other syntax errors).

> * What should we not try to do after error?  For example, after error we
> should not attempt to optimize or convert to RTL any later part of the
> file, even if this means we miss some diagnostics; we should simply do the
> basic parsing and error checking.  Are there other warning checks - beyond
> the basic constraint checking required by the standard - which should be
> disabled after error?

I don't know.  I think we should aim for simplification, and when
something undesirable comes up, fix it.  I don't want to overdesign
this.

However, there are easy ways to be less drastic than you suggest.  For
example, if something has gone wrong (with decls, say) local to a
function, we could avoid converting that _function_ to RTL or
whatever, but it shouldn't normally prevent us from continuing with
the rest of the file.

> * On error, how far should we skip before trying to make sense of the code
> again?

I think we should try not skipping at all, and fix any nasty effects
of this as they arise.  I might be naive here, but I don't think it
can be that hard.  For example, if a subexpression of an arithmetic
operator goes wonky, use an int or double of 1; it shouldn't cause any
new errors or warnings (0 could, of course).

I imagine the hardest stuff is when you have a certain kind of syntax
error, and you don't know whether you saw a decl, or struct, or ...
We should just continue to do what we do now, which appears to be to
skip to an appropriate looking ';' '}' or whatever.

Neil.