This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: adding support for column numbers
- To: Per Bothner <bothner at cygnus dot com>
- Subject: Re: adding support for column numbers
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Wed, 13 Jan 1999 18:54:23 -0500
- cc: egcs at cygnus dot com
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