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]

Re: adding support for column numbers


On Wed, 13 Jan 1999 14:41:38 -0800, Per Bothner wrote:
>In the Java print-end, we keep track of column numbers,
>for better error messages.  And cpplib will make it easier
>to also keep track of column numbers for C and C++.
>(It is difficult without an integrated cpplib, because
>macro expansion can change column numbers.)  Some
>debugging formats (at least dwarf2) can pass along
>column numbers to a debugger.
>
>So I think the time is right for adding at least a
>framework for column numbers in Gcc.  The obvious
>way is whereever we have a line number variable, field,
>or parameter, we must also add a column number variable,
>field, or parameter.  But this is a lot of work for the
>amount of benefit.  It is also wasteful to add an
>extra int column field to every decl node or every
>linenote rtx.  Instead, we can combine the line and
>column number into a single 32-bit value, counting
>on that fact that we will never need either number
>that large (though line numbers may reasonably exceed
>2**16, so short is not enough).  If we also use a
>trick where the column number is the *high-order*
>bits of the combined line+column value, plus have the
>interpretation that a column number of zero means
>a missing/unknown column (or the entire line), then
>we have "binary compatibility" between the new scheme
>and the old scheme.
[...]

This scheme seems reasonable at first sight.  I am not certain whether there
is any such thing as compatibility here: suppose code unaware of column
numbers is downstream, data-flow-wise, of code aware of them; then it will
interpret the combined field as a very large line number.  Also, shouldn't
"linecol" be an unsigned type?

On a related note, I have been hacking up cpplib while off-line; I'll start
merging next week when I get back to New York.  It is now almost ready to
replace cccp as the external preprocessor.  One change I haven't yet made
but plan for the near future is that the library interface (cpp_get_token)
will report line, column, and file info for each token directly, instead of
inserting #line directives into the output.  Also, it will never return
multiple pp-tokens in one call.  This plus symmetric changes to the front
end gets you column numbers in C.

zw


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