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: [PATCH 5/5] add libcc1


On Thu, 31 Jul 2014, Richard Biener wrote:

> Actually after looking again I was wrong.  main.c and toplev.c
> are the "driver".  So if we can make all frontends shared objects
> with their only interface being their lang_hooks that would be nice
> (of course the middle-end still needs to make gazillions of symbols
> available to that "plugin").

As far as I know, the main non-lang-hook interface provided by front ends 
is the "convert" function (and there aren't that many places outside the 
front ends that still use it).  So it shouldn't be hard to get to the 
state where each front end is only used by its langhooks.  (That's a long 
way from any sort of independent buildability, though; everything still 
embeds global information about such things as command-line options for 
all available front ends, and tree codes likewise.)

I don't personally like the relics of other such magic-named functions in 
the form of langhooks-def.h defaulting to a langhook having a particular 
name that a front end can provide

#define LANG_HOOKS_GLOBAL_BINDINGS_P global_bindings_p
#define LANG_HOOKS_PUSHDECL     pushdecl
#define LANG_HOOKS_GETDECLS     getdecls

and think it would be better for each front end to have unique names for 
these, with no such default.

I think there are a few more cases where C and C++ provide different 
implementations of a function with the same name for use by c-family code 
(and ObjC / ObjC++ issues as well, of course).

-- 
Joseph S. Myers
joseph@codesourcery.com


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