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: Column number information in 3.4.x?


On Tue, 30 Dec 2003, Per Bothner wrote:

> Chris Lattner wrote:
>
> > I remember seeing patches floating around that add column number
> > information to the GCC tree nodes, but I don't think that these are going
> > into 3.4.0.  Is it likely for column number information to get added
> > sometime in the lifetime of the 3.4.x series, or is this a 3.5+ only
> > feature?
> I'm thinking of it as a 3.5 feature.  It's a major change, at least the
> way I'm approaching it, since I'm basing it on the line-map tables, and
> expanding their use from cpplib to the entire compiler.

Ok, that's unfortunate, but makes sense.

> I guess it someone made a strong enough case it could be added in 3.4.x,
> but I think it unlikely.

I am primarily interested in making the information available in debug
information, but it would also be a huge win for compiler diagnostics.
Exposing it to debug information allows the debugger to provide the user
with a substantially nicer interface, IMHO, but this is obviously a
quality-of-implementation issue.

> Richard H has given approval for me to check an initial set of patches
> into the tree-ssa branch.  However, as I'm busy with other things rights
> now, I'm thinking I might wait until the 3.4 branch is created and check
> it into mainline instead.  But I can check it into the tree-saa branch
> sooner if requested or I go back to working on it before the 3.4 branch.

That's interesting.  Putting it into the post-3.4 mainline would be the
useful, at least for my purposes. :)

> The current patch only adds column number support to the source_location
> cookies.  I have other older patches to replace struct location_t by
> source_location; this would add column number support to the rest of the
> compiler.  These patches would need to be updated.  In addition,
> front-ends that don't use cpplib would need to be updated to use
> line-map and source_location.  This should be relatively easy with the
> more encapsulated line_map API that Richard pushed me to but I haven't
> really looked at it.

Ok, that makes sense.  Until the front-ends all get updated, they can
always just provide 0 as the column number to preserve current behavior...

Thanks for the update!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/


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