[patch, fortran] pr21061 - gfortran ignores -Werror
Brooks Moses
brooks.moses@codesourcery.com
Tue Nov 7 21:30:00 GMT 2006
Bernhard Fischer wrote:
> Index: error.c
> ===================================================================
> --- error.c (revision 118542)
> +++ error.c (working copy)
> @@ -525,17 +525,18 @@
> if (gfc_suppress_error)
> return warning ? SUCCESS : FAILURE;
>
> - cur_error_buffer = (warning && !warnings_are_errors)
> - ? &warning_buffer : &error_buffer;
> + cur_error_buffer = warning ? &warning_buffer : &error_buffer;
> cur_error_buffer->flag = 1;
> cur_error_buffer->index = 0;
>
> if (buffer_flag == 0)
> {
> - if (warning && !warnings_are_errors)
> + if (warning)
> warnings++;
> else
> errors++;
> + if (warning && warnings_are_errors)
> + errors++;
> }
> va_start (argp, nocmsgid);
> if (warning)
>
>
> Bernhard Fischer <>
> * error.c (gfc_notify_std): Disregard warnings_are_errors when
> deciding which logbuffer to use. Also increment warnings if
> warnings_are_errors is set.
>
> Would that be ok?
It looks ok to me, but I can't approve it.
Also, on going through the list of affected functions in the patch I'm
submitting, I noticed that if you're putting warnings in the
warning_buffer regardless of warnings_are_errors, then
error_warning_check needs to be updated to optionally increment errors.
>>(In particular, I'm wondering if this has to do with lines 2606-2610 of
>>match.c, which implement a gfc_notify_std_now sort of thing assuming
>>that if gfc_notify_std has returned FAILURE that the result is in
>>error_buffer, or whether there's a more global reason for it...?)
>
> The initial reasoning from my part was to use the error buffer even for
> warnings if Werror was set. This was dropped for the sake of simplicity
> and since it was not really needed AFAICS.
>
> match.c lines 2599-2604 really look like they want gfc_error_now instead
> of the gfc_error, gfc_error_check combo. Or is there a subtile reason
> for the combo?
That's how I'd read it, too. I don't see that the combo does anything.
- Brooks
More information about the Fortran
mailing list