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] Remove TARGET_ADDR_SPACE_KEYWORDS target macro


On Wed, May 26, 2010 at 08:09:57PM +0200, Ulrich Weigand wrote:
> Mike Meissner wrote:
> > On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> > > Ulrich Weigand wrote:
> > > 
> > > >> So the question is: The goal is to have hooks, not macros, right? If
> > > >> so, can reviewers please take care to reject patches that introduce
> > > >> new macros?
> > > > 
> > > > I don't know to which extent this is a formal goal these days, but I
> > > > personally agree that it would be nice to eliminate macros.
> > > 
> > > Yes, the (informally agreed) policy is to have hooks, not macros.  There
> > > may be situations where that is technically impossible, but I'd expect
> > > those to be very rare.
> > 
> > For the target address space stuff, it is to the __ea keyword.  You don't want
> > a target hook that is called on every identifier, but instead you want a target
> > hook that is called in c_parse_init (in c-parser.c) and init_reswords (in
> > cp/lex.c) to set up the keywords.  The target hook would have to duplicate the
> > functionality of all of the setup that c_parse_init and init_reswords do,
> > particularly if they have different semantics.
> 
> It looks like this may be simpler than I thought.  The following patch
> introduces a "c_register_addr_space" routine that the back-end may call
> to register a named address space qualifier keyword.  (This could be done
> either statically at start-up, or even dynamically e.g. in respose to a
> target-specific #pragma.)
> 
> In the current patch, the SPU back-end uses somewhat of a hack to actually
> perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
> Note that this macro is already being used by the SPU and several other
> back-end for similar hacks.  It seems that it might be a good idea to
> replace this by something like a "register_target_extensions" callback
> in targetcm, but that can probably be done in a separate patch.

Note, many of the things done by REGISTER_TARGET_PRAGMAS deal with the
preprocessor and keywords, which are used by the C-like front ends, but not
used for Ada, Fortran, etc.  Those front ends don't link in libcpp.  So, you
need something in <machine>-c.c that sets the hook, rather than moving it to
<machine>.c.

-- 
Michael Meissner, IBM
Until June 14: 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
After June 14: 5 Technology Place Drive, MS 2757, Westford, MA 01886, USA
meissner@linux.vnet.ibm.com


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