This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, fortran] PR18923 segfault after subroutine name confusion
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.