Clean ups for error handling

Gabriel Dos Reis gdr@codesourcery.com
Thu Jul 20 17:14:00 GMT 2000


Zack Weinberg <zack@wolery.cumb.org> writes:

| Now that we have diagnostic.c, we can put fancy_abort there instead of
| in rtl.c.

Zack,

It is Ok to put in diagnostic.c any language-independent diagnostic
subroutines.  Diagnostic.c should, eventually, contains only such
kind of beasts.


| No one uses set_fatal_function, 

That part of code was lifted, as is, from toplev.h a while ago --- it
is certainly possible that isn't used.  


| ...and it causes us to need va_copy in
| diagnostic.c, which is not portable.  (Did we or did we not have a
| long argument about this last week?)
| 
| Use __FUNCTION__ instead of __PRETTY_FUNCTION__ in all the ICE
| messages (they're the same thing in C), and put a default definition
| in system.h, which reduces the number of #ifdefs.
| 
| Add a guard against recursive entry to the error-handling routines in
| diagnostic.c.  This is inspired by the guard for recursive aborts in
| the C++ front end.

Hmm, OK.

[...]

| @@ -1482,8 +1473,12 @@ report_diagnostic (msg, args_ptr, file, 
|  {
|    output_state os;
|  
| +  if (diagnostic_lock++)
| +    error_recursion ();
| +
|    if (!count_error (warn))
| -    return;
| +    goto out;
| +
|    os = diagnostic_buffer->state;
|    diagnostic_msg = msg;
|    diagnostic_args = args_ptr;
| @@ -1494,4 +1489,62 @@ report_diagnostic (msg, args_ptr, file, 
|    finish_diagnostic ();
|    output_destroy_prefix (diagnostic_buffer);
|    diagnostic_buffer->state = os;
| +
| + out:
| +  diagnostic_lock--;
| +}

For readability purpose I'd much prefer:


    if (count_error (warn))
       {
          os = diagnostic_buffer->state;
          diagnostic_msg = msg;
          diagnostic_args = args_ptr;
          /* ... */
          finish_diagnostic ();
          output_destroy_prefix (diagnostic_buffer);
          diagnostic_buffer->state = os;
       }

   diagnostic_lock--;

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com


More information about the Gcc-patches mailing list