Ada, treelang needs to be converted to --enable-mapped-location
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Wed Oct 6 23:25:00 GMT 2004
So is the objection really to its placement in libcpp, a library that
is otherwise unused? Maybe this is just a code organization issue.
What if it were in libiberty instead? Would that calm people down
and make clear that it's not part of the GCC backend?
No, that isn't the issue.
The issue is that there's already *a lot* of code in the Ada front-end
(approximately 2,000 lines) dealing with source file issues. That code deals
with numerous issues unique to Ada and GNAT (such as tracking casing of
identifiers and keywords, computing checksums and timestamps, and looking at
licenses).
Linking Ada code to C is not hard, but has a cost, both in clarity and in
losing the ability to inline the code being called. It's worth doing that
linkage if (and only if!) there is some benefit in code sharing obtained from
that linkage. The GCC backend is a perfect example of such a gain. Hashing
code is a good example where it's a bad idea because the code is small enough
that the benefit of sharing is outweighed by losing the ability to inline.
In this case, if sinput.ad{s,b} used line-map, it's very doubtful we'd
actually save any code because of the need to map all the extra information
into the data structure used by line-map. We'd also lose inlining.
Moreover, the complexity of the interfacing would make the code much less
clear. And for what gain, to share 500 lines of code?
When the file/line structure isn't being used for significant amounts of
data, such as in the C and C++ front ends and the language that the code
using line-map is the same as line-map (C), the sharing does have a benefit.
I still haven't heard any reason why we simply can't use the existing Ada
Sloc as the source_location within GCC for Ada.
More information about the Gcc
mailing list