This is the mail archive of the 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: Ada, treelang needs to be converted to --enable-mapped-location

On Sep 30, 2004, at 13:05, Per Bothner wrote:
I haven't seen any real reason why the line_table mapping would be a
poor fit for Ada, or why there would be any problem (performance or
otherwise) with using it for Ada.

We use the line_table for C/C++/ObjC, Java, and Fortran without problem.
I don't see why Ada would have any problem.

Because we don't build GCC trees during parsing. Also, GNAT already has
a perfect mapping from locus to filename/line/column, and you're suggesting
adding another data structure on top of that. This at least duplicates

I don't know why you refer to the "back end".  line-map.[ch] is a self-
contained "library" that was originally used for cpplib, which is part
of the C/C++ *front-ends*.  There are no "back-end" calls.

The design of GNAT is such that the front end (all compiler files written in Ada, except[bs]) should not need to know about the GCC back end or its peculiarities. That this goal has been achieved to a large part has been shown by implementing non-GCC back ends for JVM and AAMP.

At a more practical level, the decoupling of front end and back end
ensures that most changes in the GCC back end do not affect the Ada
front end.

I'm not objecting to doing work to update Ada, I object to
having knowledge about GCC 4.0.0's specific line numbering
implementation spread out over the front end sources.

I think the ideal approach is to view the locus as private to the front ends.
Then we just use the Ada "Sloc" as locus and provide the necessary
functions to map this locus to file, line, column information.

This slightly complicates 90% of the compiler (trees, rtl, debugging, error handling) adding a extra level of indirection because you don't want to add 10 lines to the Ada front-end. That doesn't seem like a good tradeoff to me.

No, it should not make any difference for the compiler. If it would, that clearly would illustrate that this would create a tight coupling between the front end and the back end. If 90% of the compiler is aware of the details of the implementation of how locations are stored, that means there is something very wrong in the design.


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