[patch] Split c_register_addr_space in separate functions for C and C++ front ends

[Ulrich Weigand]

Steven Bosscher wrote:

> The biggest problem is with the spu target.  It hooks into the front
> end with a rather ugly hack: It registers a new keyword via the
> REGISTER_TARGET_PRAGMAS target macro. This results in a function in
> c-common.c that uses the C C_IS_RESERVED_WORD definition, which it
> takes from c-tree.h.  Using C_IS_RESERVED_WORD is very wrong,
> especially since the definition of it is different between the C and
> C++ front ends: C uses TREE_LANG_FLAG_0, C++ uses TREE_LANG_FLAG_5).

Sorry for not noticing this; I had assumed reserved word handling
was common since all the RID_ stuff seemed to be in c-common.h ...

> gcc/ChangeLog:
> 	* c-common.h: Add FIXME for awkward split of c_register_addr_space.
> 	* c-common.c (c_register_addr_space): Remove here.
> 	* c-declc (c_register_addr_space): Re-add here.
> 
> cp/ChangeLog:
> 	* tree.c (c_register_addr_space): Add stub.

Just a minor suggestion: if you're going to move this function anyway, what
about moving it near c-parser.c:c_parse_init and cp/cp-lex.c:init_reswords,
respectively, where the other reserved words are registered, and where the
logic was copied from?

> +/* Stub for c-common.  Please keep in sync with c-decl.c.
> +   FIXME: If address space support is target specific, then this
> +   should be a C target hook.  But currently this is not possible,
> +   because this function is called via REGISTER_TARGET_PRAGMAS.  */

I'd be happy to move the call site anywhere else you suggest.  But I'm
wondering what you mean by "C target hook".  The struct targetcm, which
I'd been thinking of using, seems itself to contain "C-family" target
hooks, and not "C-only" target hooks, right?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com