This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery
- From: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: FX <fxcoudert at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>
- Date: Fri, 28 Nov 2014 02:46:12 +0100
- Subject: Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery
- Authentication-results: sourceware.org; auth=none
- References: <CAESRpQCGfALwFN_PgLxwkf7KCmByzBevrvGY634PhBFCXX6zVg at mail dot gmail dot com> <54777B77 dot 3050002 at net-b dot de> <CAESRpQD3Qs7ASqZnRzxcFnEqMUKFb4EGydVKg4Y99QXawfjTTA at mail dot gmail dot com> <5477ACB3 dot 2000409 at net-b dot de>
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.