Re: On several ICE bugs: 619, 657, 676, 686, 745 etc.

[Jason Merrill <jason at redhat dot com>]

>>>>> "Cosmin" == Cosmin Truta <cosmin@cs.toronto.edu> writes:

> As I was wandering around the GNATS system, and I noticed that many bugs
> of the category "G++ - ICE on illegal code" are posted, and all of them
> refer to the following code from "gcc/cp/decl.c", fnc. "finish_function":

>   if (current_binding_level->parm_flag != 1)
>     my_friendly_abort (122);

> Basically, it makes cc1plus die when a big category of syntax errors are
> encountered in the body of a function.

FWIW, this is the sort of bug report that the 'confused by earlier
errors' code was intended to avoid; a crash after a valid error
message is suboptimal, but IMO low priority.

> I have removed the code that stops the compiler, and I was able to run it
> on big code that contained many errors as above. The compiler showed all
> the errors, until the end, without dying.

> So, if you don't wish to continue receiving many other bug reports on the
> same matter, I suggest the following patch (unless you have a better
> solution). You might consider "#if 0"-ing the code instead of removing it,
> if you still want it there.

No, it's important to leave it in to make sure that the compiler is
behaving sensibly; see below.

> I would also like to ask you something about my_friendly_abort().
> For my specific purposes, I would like cc1plus to run as much as possible
> on erroneous code, and to show as many errors as possible.
> Is it ok if I will just compile out my_friendly_abort()? I believe that a
> situation that cannot be handled will be trapped anyway by the signal
> mechanism. Is there any other reason for my_friendly_abort to be there,
> except debugging purposes?

That should be fine; it is only there for debugging purposes, to check
that the internal representation of your code is still internally
consistent, that things haven't gone horribly wrong.  In the testcase
in question, the syntax error screws up the internal representation
pretty badly; thus the abort.  Ideally, we would do something sensible
to recover, but that's not always feasible.

It may be reasonable for the my_friendly_abort to only give an error,
not stop the compile; that way later errors can still be diagnosed,
though we run the risk of runaway error messages.

Another, less extreme option would be to change many instances of
my_friendly_abort to compiler_error.

Thoughts?

Jason