Re: Ada, treelang needs to be converted to --enable-mapped-location

[Geert Bosch <bosch at gnat dot com>]

On Oct 6, 2004, at 09:48, Zack Weinberg wrote:
> line-map.[ch] should not be considered part of GCC in this context.
> The proper analogy is to code in libiberty, which is shared among many
> projects.  There is no reason the Ada front end cannot make use of it
> when linked to some other back-end (modulo source packaging issues).

It is just wrong for GCC to require front ends to parse and analyze
sources in a particular way. During the entire parsing and analysis
of the Ada sources, we never call into any of the C part of GCC.
The only code executed is the Ada code in the gcc/ada subdirectory.

This is ideal from a maintenance point of view, since the separation
between front end and back end matters is localized in just a few
files comprising Gigi. So, even for large changes in the back end,
such as the recent move to tree-ssa, no front end changes are required.
Similarly, when GCC infrastructure and data structures change, no one
needs to look at or change the Ada sources. We'd like to keep it
this way.

As GCC will implement more languages over time, such a separation is
even more necessary. Just think of a GCC with 20 different front ends.
If every change to a data structure, such as the line map, would
require changes throughout these front ends, maintenance would be
a nightmare.

The reason that especially the C and C++ front ends are so intertwined
with the rest of GCC is partially historical and partially political.
However this has made GCC more of a mess than it should be. Fortunately,
we are moving (slowly) in the right direction by having the front ends
generate tree-representations of an entire compilation unit, before
handing this off to the middle- and back end. Similarly, semantics
of this tree are incrementally tightened.

This GENERIC tree representation is the data structure that needs
to be constructed. The specification that these trees must adhere to
should be the basis of the interface between front end and back end.
Ideally, for a compiler bug, one could just look at the GENERIC
tree dump and the specification of GENERIC and decide wether the
front end or the back end is wrong.

How the front end generates its trees should be of no concern.
My objection against using the line-map.[ch] "library" is that
its "specification" makes so many assumptions on how its callers
are structured, that it ends up specifying how to implement
a front end instead of just providing a way of to build a mapping
from locus to file, line and column.

I see three solutions, listing in order of preference:
  -  Allow front ends to specify the mapping from "Locus" to
     file/line/col. The locus is just an abstract type encoded
     in a 32-bit value, and front ends provide hoods to get
     file/line/column information. This would fit well with
     Ada and Fortran front ends, and completely eliminates
     the need for any extra overhead of the line-map data
     structure.

  -  Make the line-map interface a bit more flexible, so that
     mappings can be created in arbitrary order without large
     performance penalties.

  -  Add an extra pass to Gigi, which sorts all loci by original
     source order and then uses the somewhat clumsy interface of
     line-map to generate the required data.