This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery


On 27 November 2014 at 23:58, Tobias Burnus <burnus@net-b.de> wrote:
> Manuel López-Ibáñez wrote:
>> Sure, but I would like to test specifically triggering and discarding
>> the gfc_warning that I converted (or another single one that you
>> suggest), if this were possible.
>
>
> Hmm, theoretically, it would be possible. However, my feeling is that there
> is no such case. What would be needed is something which is ambiguous, the
> compiler assumes first the wrong kind of statement, fails, and retries is
> with a different kind of statement.
>
> That's simple. However, either one has already aborted (gfc_error or
> NO_MATCH) *before* reaching a gfc_warning - or the code is valid and, hence,
> the buffered warning is printed.

Then, I don't understand the point of gfc_warning.

If gfc_warning is never reached, then we could have used gfc_warning_now.
If the warning is printed, then gfc_warning was reached, thus we could
have used gfc_warning_now.

The only difference is that gfc_warning_now will print the warning as
soon as gfc_warning is reached, but since there is at most one
buffered warning and there can not be a previous error, then this
should not make a difference. What am I missing here?

>> Why does it ICE? At worst it should give a wrong location, but the
>> computation of the offset is fairly similar to what Fortran already
>> does. Could  you give me a patch+testcase that ICEs?
>
> However, the change
>
> -         gfc_warning_now_1 ("Line truncated at %L", &gfc_current_locus);
> +         gfc_warning_now ("Line truncated at %L", &gfc_current_locus);
>
> still triggers an ICE with "gfortran -Wall test.f90" and with "test.f" (two
> locations in scanner.c; see attached test cases and attache patch). The
> backtrace for test.f90 is:

The problem seems to be that linemap_position_for_loc_and_offset
cannot handle an offset larger than the column_hint. Fortran hardcodes
that to 120. There are two bugs there: (1) we should not crash, at
worst we should use offset=0 and (2) we should update the column_hint
to the largest column seen. I'm testing a patch that seems to fix the
problem.

Cheers,

Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]