This is the mail archive of the gcc-patches@gcc.gnu.org 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: [4.5] [RFC] Move line-map.* to its own library (libloc)


2008/11/15 Tom Tromey <tromey@redhat.com>:
>>>>>> "Manuel" == Manuel López-Ibáñez <lopezibanez@gmail.com> writes:
>
> Manuel> The following patch moves line-map.* and other stuff related to
> Manuel> locations to a library called libloc. Anything that only needs
> Manuel> location info does not need to link against libcpp or include libcpp.h
> Manuel> anymore.
>
> Is the rationale for this just to avoid pulling in the rest of libcpp?
> That doesn't seem like a big enough benefit to justify making a new
> library.

No, that is a secondary effect of the main motivation. The main
motivation is to start making GCC more modular. The current situation
is a mess and I believe it is one (among many) causes that GCC is so
complex, difficult to learn, difficult to modify, etc. By comparison,
the clear and beautiful modular design of LLVM/Clang is one of the
main reasons of its rapid development and success.

This was simply the lowest-hanging fruit in this respect. Other
candidates to move to its own library are: the shared
diagnostics/pretty-print stuff, the reading of files/character
conversion, the command-line options handling and probably other
stuff. Anyone willing to work on this would be doing a major
contribution to GCC's future survival.

> I can't approve or reject this part, though.  Some global reviewer
> would have to.

I wasn't seeking approval just yet. This still needs serious work. I
was seeking comments and perhaps help to cleanup all the build-related
bits.

>
> One oddity here is that BUILTINS_LOCATION is not actually enforced, or
> even known about, by line-map.  It is only "correct" because gcc is
> careful to arrange things that way.  So, it isn't clear that moving
> this to line-map is enough -- in the sense that, there is still an
> un-obvious dependency between how gcc is coded and what the #define
> claims.  So, I don't think moving this makes sense unless it is
> accompanied by some other changes to line-map -- BUILTINS_LOCATION is
> really an implementation detail of gcc, not part of the interface.

That is a really good point. Also, the location corresponding to 1
(COMMAND_LINE_LOCATION?) is not defined there, I will have to look it
up or define it. Anyway, COMMANDLINE_LOCATION and BUILTINS_LOCATION
could be defined by libloc when a new line-map is built. Moreover, the
libloc interface does not need to be the interface of line-maps.
Line-maps is just the (current) internal working of libloc, we may
decide change it in the future. A better interface would define the
location-related functions that we need and not simply the functions
that line-map provides.

In that sense, BUILTINS_LOCATION could be defined in libloc. The point
is that this library is meant to be used by GCC and nothing else, so
if BUILTINS_LOCATION is (or could be) used by anything that requires
libloc, then it doesn't belong in toplev.h or input.h.

> Why is expand_location a #define now?

The old expand_location assumes a global line_table available. The
line_table in libcpp is not a global variable. Instead of updating all
calls to expand_location to take an explicit line_table, I defined
expand_location_1 but that was just a temporary hack.

expand_location should take an explicit line_table and all calls
should be updated.

BTW, is the incremental compiler using a global line_table also?

Cheers,

Manuel.


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