This is the mail archive of the
mailing list for the GCC project.
Re: ICE in change_address at emit_rtl.c
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
> 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
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
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.