Manuel López-Ibáñez wrote:
On 27 November 2014 at 23:58, Tobias Burnus <bur...@net-b.de> wrote:
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.
I think the idea is that a warning could be printed in the wrong code
path (assumption of which kind of statement or expression one has) – and
then one re-tries a different code path, see that it fits and drops the
buffered message.
Grepping through the 132 gfc_warning, I have the impression that this
cannot happen, i.e. that the message is always shown. However, in order
to be sure, I had to check all code paths and had to think about ways
they become unreachable – with the chance that I miss something.
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.
I concur; the question is only whether my impression is correct. You
could try to map gfc_warning to gfc_warning_now_1 and see whether
something in the testsuite breaks.
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?
(a) That, conceptionally, warning buffering makes sense, if you
buffering errors for rewinding - even if it only occurs for error and
not for warnings. (b) That I might have missed some code path. (c) That
one might add such a code path in future.
Except for (b), I do not see a reason not to map gfc_warning to
gfc_warning_now. If one later needs buffering, one can still take
gfc_error as model for implementing it as it surely needs buffering.
FX, Steve et al.: Comments or additional facts?
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.
Fortran (old code) chops off items from the beginning of the line if the
column number is high (and also trimps the output line to the right).
Thus, instead of
print 'aa.................'
....................(1)
is just show
aaaaaaa'
(1)
I don't know how C/C++ handles this. If one doesn't chop off, the output
can become extremely long – especially with "topformflat 0". And then
the "^" is also not helpful as one has to count the numbe of lines ...
Tobias
