[patch, fortran] PR18923 segfault after subroutine name confusion

[Bernhard Fischer]

On Tue, May 22, 2007 at 08:31:28PM -0700, Jerry DeLisle wrote:
>Tobias Burnus wrote:
>>Jerry DeLisle wrote:
>>>I would like to add this one additional change.  We need to give it up
>>>at some point and one of these test cases triggers this.  It seems to
>>>make sense to me.  Let me know if this is OK and I will include it. 
>>>Regression tested of course and it obviously passes.
>>>Index: symbol.c
>>>-     gfc_internal_error ("gfc_get_default_type(): Bad symbol");
>>>+     gfc_fatal_error ("Symbol name confusion at %C");
>>
>>Hmm, I like that it shows the position, but it only shows "Fatal Error:"
>>instead of "Internal Compiler Error:". Internal errors should never
>>happen (they are by definition a bug in the compiler) and should be
>>reported.
>>
>>"Fatal Error:" on the other hand sound more like user errors which
>>should not be reported.
>>
>>I think invalid user code should and are rejected earlier, namely in
>>gfc_match ("Invalid character in name at %C"). Therefore, I would prefer
>>an gfc_internal_error. Couldn't you use something like:
>>
>>     gfc_internal_error ("gfc_get_default_type(): Bad symbol at %C");
>>
>>this gives more debugging information but still implies the ICE. If I
>>read error.c correctly, this should work.
>>
>>Tobias
>>
>This is one of those invalids where we ought to quit after the syntax error 
>is found.  Instead we move on into resolve and get additional nonsense 
>messages before finally hitting the internal error.  I have an upcoming 
>patch, still being developed and tested to attempt to intercept these and 
>bail out earlier.

Would calling gfc_check_error() there be sufficient to bail right at
that spot?
>
>I will commit the segfault fixes, then work on this new patch to catch the 
>syntax and quit.  After that I will get the test cases in place.