Ada, treelang needs to be converted to --enable-mapped-location
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Thu Oct 7 05:56:00 GMT 2004
The problem here is that we cannot make a decision for Ada independently
of the rest of GCC because the data structures (*_DECL tree nodes) in
question are shared among all GCC front ends. There is a clear benefit
to the other front ends from using this new approach: the compiler
itself goes faster with no loss in functionality.
But that's not the issue here. We aren't talking about the tree nodes, but
about the meaning of what a "source location" is: as far as the tree nodes
are concerned it's an opaque data type.
If that means translating from the current Ada representation to the
GCC representation at the last minute, when the Ada front end
translates all its other data structures, that's fine. I don't
understand how that can be impossible. It might be difficult for the
Ada maintainers, but that may be the price paid for being independent
of the core GCC data structures, and thereby providing the ability to
reuse the Ada front end with other back ends.
The issues are the following:
(1) Source location handling is done very early in the Ada front end and with
a lot of Ada-specific processing. Using line-map at this point creates two
problems:
(1a) Linking to that file in a context where the rest of GCC isn't used and
it's the only file from that tree and also the only C file creates a
build/packaging issue.
(1b) Because there's so much additional file and line handling, superimposing
that on top of the existing line-map routines adds significant complexity to
the existing code and more than wipes out the benefits of sharing that small
piece of code.
(2) If we do it in Gigi, the issue is that the line-map code expects to see
locations created in increasing order, but there's no guarantee that the
nodes will be processed in that order. What we can do is add a pre-pass that
walks the the tree and converts each Ada Sloc into a (file, line, column)
triple and then sorts all the triples. We can then call the line-map code
for each such triple and make a hash table to be used later to map an Ada
Sloc to a GCC source_location.
However, what the above code does is make a mapping from one 32-bit opaque
datatype that encodes a (file, line, column) triple to a different 32-bit
opaque datatype that encodes *exactly the same thing* in a different way.
This seems pointless.
My proposal is basically to take the view that source_location is an unsigned
int that's an opaque datatype used to encode a (file, line column) triple.
This datatype can either be defined in the front end (in which case it
provides a language hook to produce that triple from the encoding) or it can
use routines provided in line-map.c to generate the encoding.
More information about the Gcc
mailing list