Question/proposal for USE_MAPPED_LOCATION and Ada
Steven Bosscher
stevenb@suse.de
Wed Oct 6 22:21:00 GMT 2004
On Wednesday 06 October 2004 22:54, Geert Bosch wrote:
> Steven,
>
> You mentioned in an earlier email that the Fortran compiler
> has a line map as well. A quick look at the sources seems
> to indicate that Fortran already has a locus allocated for
> every position,
Nope. Fortran has already been converted to use source_location
to store locations.
> and langhook as described by Richard could
> be trivially implemented by using an indirection. Does
> that seem correct to you?
For Fortran, please no. I see no reason why we would need to have
this indirection, source_location seems to work Just Fine for Fortran.
> As Zack mentioned, having two isomorphic representations of the
> same thing wastes time and space, so it would be nice to avoid
> using line-map for those front ends that do not need it.
"Do not need it" is the part that remains vague to me in this whole
discussion. My (I'll admit, limited) understanding of all this is
that:
- The goal is to have a shared GCC diagnostics machinery;
- For that all front ends need to represent locations using
some shared representation;
- We *always* had a backend representation of filenames and
line numbers in the middle/back end. All Per does is change
the representation to some thing that needs linemap.[ch].
Having two isomorphic representations doesn't seem like such a big
deal to me. Always been like that AFAICT: Ada has its own (very
nice) diagnositics machinery, and it uses its own representation for
locations. Both is also used to be true for Fortran. The Fortran
front end used to simply translate its own location information to
that of GCC when translating from our intermediate representation to
GENERIC (see gfc_{get,set}_backend_locus).
I don't think having your own location representation is a waste of
space and time. Zack likes clean, I'm more pragmatic: It's a design
decision.
In the Fortran case, the question is: Does GCC provide adequate
language independent diagnostics machinery? (A: apparently yes, and
with a little luck we'll even get column information back!).
In your case, the question is: Do you want our front end to depend on
linemap.[ch] outside gigi? If not, then implement your own location
representation, translate your representation to that of GCC, accept
the space and time penalty, and be done with it.
Let's be realistic, this penalty really is not that big if you already
are translating your own front end internal representation to GENERIC.
There still appears to be some concern about efficiency (or anyway,
*speculation* about efficiency, not numbers), but I think of that as a
detail of the implementation, which can be improved if it turns out to
be a real problem.
But since y'all seem to see enough other problems to have this whole
discussion, I probably missed a few important points ;-)
Gr.
Steven
More information about the Gcc
mailing list