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

Geert Bosch wrote:

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.

No, most of the compiler does not need to know the details of how locations are stored.

However, if we're to follow your suggestion (as I take it), we
need two typedefs:
(a) source_location int as managed by libcpp/line-map.c and used by
(b) a different abstract typedef that be used in most of the gcc,
and whose "meaning" would be defined by language front-ends.  It
would be defined as (a) in most front-ends, but not Ada.

Accessor macros/functions like DECL_SOURCE_LINE would continue
to be defined in terms of DECL_SOURCE_LOCATION and LOCATION_LINE.
However, LOCATION_LINE would become a call-back to a language
front-end function.

I think these changes would a add an small extra level of complication
and confusion.  It's minor and managable, but it is an extra call-back
interface, which are in principle to be avoided.

It is also possible to make the line_maps type extensible by putting
function (method) pointers in the structure, but that also seems
unnecessary generalization at this point.

Bottom line: you're going to have a hard time convincing people to
make this change for sake of Ada, given that it's a minor extra
conversion step for Ada.  Plus given the historical frustrations
we've had with gnat means we're not going to bend over backwards to
be optimal for Ada if it complicates the rest of the compiler.
(Speaking personally, of course, not with my SC hat on.)
	--Per Bothner

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