This is the mail archive of the
mailing list for the GCC project.
Re: gcc-in-cxx update / multi-targeted gcc
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 29 Apr 2009 06:47:04 -0400
- Subject: Re: gcc-in-cxx update / multi-targeted gcc
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:
So far, I have only made gcc-in-cxx related and a few general
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
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.