This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]