This is the mail archive of the gcc@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: Major debugging breakage


law@redhat.com wrote:-

> I don't necessarily think this is the problem -- assuming that SRC_LINENO is
> used to output diagnostic messages.

No, it's used to update lineno as the front end digests tokens that
have been preprocessed (which is what is used for diagnostic messages
after all).  The next token that comes in through c_lex sets lineno to
src_lineno.

This might seem weird, but it actually makes sense.  Each token also
has its own idea of line number, but in the case of a token from a
macro expansion, this line number is the line number of the #define
(which we don't want or use yet, but which we could use to give some
fancy diagnostics in future).

src_lineno indicates where CPP is in the file, without having to have
a per-token function call (the alternative is to make cpp_reader a
complete type for the front ends, but this loses the abstraction).  I
can't immediately remember the reason cb_line_change doesn't set
lineno directly, but there is a good reason (I have a feeling it might
be #pragma-related).  When I re-discover this, I need to document it.

> It seems to me that we should have stored the line number into the
> statement tree when we first encounter the statement.  We should
> then extract that line number from the statement tree when we
> convert the tree into RTL.

Yes, this makes the most sense to me, too.  I think in 3.2, we should
try to get the parsers to be the only users of "lineno"; with
everything else getting it from the trees or RTL they are handling.

Neil.


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