In order to be able to use namespaces in my endeavour to support gcc with multiple targets, I've first done a merge from the gcc-in-cxx branch.
For my initial implementation, I choose as configuration --target=m32r-elf --with-extra-target-list='sh64-elf arc-elf32' . I've found some issues with gcc-in-cxx both specific to these targets, and specific to (parts of) compiler passes that are only compiled for a subset of all tagets, which include one or more of the above mentioned three. You can find these in the branch: svn//gcc.gnu.org/svn/gcc/branches/multi-target-4_4-branch So far, I have only made gcc-in-cxx related and a few general checkins there. I haven't got to the stage where I could link the multi-targetted gcc together - it's still missing stuff like target option related variables. However, I have already noticed that you are pushing the target vector in a nonsentical direction: you are using target-specific enums, like enum reg_class . We can't have the target vector refer to these enums, since they are different for each target. Something which I miss in C++ is a way to declare that a function uses an integral type to pass an enum value (in arguments or return value), and then at function definition time only check that the integral type is sufficently large to hold the enum, and then for type checking purposes treat the parameter / return value as if it had been declared as this enum. FWIW, the target vector is more an obstruction than a help to make gcc multi-targeted. macros that change the way an rtl optimization pass work just fine - I then end up with different versions of the rtl optimization pass in different namespaces, which are accessed by pass lists which are initialized by code living in the same name space. My plan (I haven't started implementing this yet) for enum machine_mode is to have each number denote a mode with the same number of bits and mode class on all configured targets on which they denote a usable mode. I'm not sure yet if it will be helpful to diable modes not usable on a target by making them MODE_RANDOM. What are your thoughts on using gcc extensions for gcc-in-cxx ? We can work around the enum issues by liberally sprinkling casts all over the code, but we are really working against the language there. We could try to implement en extension to describe integral types used to pass enums, where the enums only need an unqualified name match. E.g. we could have: typedef int enum_reg_class __attribute__ ((enum (reg_class)); and have that be compatible with mips::enum reg_class for a funtion definition in the mips namespace, with spu::enum reg_class for a function definition in the spu namespace, and with plain enum reg_class anywhere. Another enum problem is enum attr_cpu / enum processor_type in the sh machine description. We need a variable (sh_cpu aka sh_cpu_attr) with this type to be visible inside the attributes generated by genattrtab. Choices to solve these kind of problems would be: - introduce another target header which is guaranteed to be included only after enum definitions from generator files are in effect. - allow the gcc extension of statement expressions to be used in target descriptions, so that a macro could provide an extern declaration of a variable before using its value.
