Hello All, I am in the process of merging 4.6 (i.e. current trunk) into the GCC MELT branch. However, I want very much the same source code to be able to run as a plugin to 4.5 & as a plugin to 4.6. So precisely, I want to have gcc/melt-runtime.c from the MELT branch compilable as a plugin melt.so both for GCC 4.5 & for GCC 4.6. Of course I am only speaking of *source* compatibility (I do not want the *same* melt.so shared object binary to be usable as a plugin for both 4.5 & 4.6, and I believe it is not possible and should not be wished; obviously compiling melt-runtime.c to melt.so would need different flags for 4.5 & 4.6).
For those unfamiliar with MELT http://gcc.gnu.org/wiki/MELT it is a lispy domain specific language to code GCC extensions in, with powerful pattern matching suitable to match GCC tree-s & gimple-s etc., translated (by itself) into C code suitable for GCC. MELT has its own copying garbage collector, built above ggc (so the copying is done from the MELT nursery, and the old generation is GGC's heap). The minor issue is to distinguish compilation for 4.5 from compilation for 4.6. I believe that a simple trick like below is enough. This is code I am adding inside my gcc/melt-runtime.h /*** NOTE: june 2010. GCC 4.6 has a new typed garbage collected allocator; so any GTY-ed struct FOO_ST should be allocated using ggc_alloc_FOO_ST or ggc_alloc_cleared_FOO_ST. ***/ #if BUILDING_GCC_VERSION >= 4006 && defined(ggc_alloc_typed) #define MELT_HAS_TYPED_GGC_ALLOC 1 #else #define MELT_HAS_TYPED_GGC_ALLOC 0 #endif By the way, perhaps defined(ggc_alloc_typed) would be enough above. Of course the GGC allocation code should be different. For instance, in my gcc/melt-runtime.c the function forwarded_copy would contain the following piece of code, where struct meltobject_st is a GTY-ed struct from gcc/melt-runtime.h #if MELT_HAS_TYPED_GGC_ALLOC struct meltobject_st *dst = ggc_alloc_cleared_meltobject_st (oblen * sizeof (src->obj_vartab[0])); #else /*!MELT_HAS_TYPED_GGC_ALLOC*/ struct meltobject_st *dst = (struct meltobject_st *) ggc_alloc_cleared (offsetof (struct meltobject_st, obj_vartab) + oblen * sizeof (src->obj_vartab[0])); #endif /*MELT_HAS_TYPED_GGC_ALLOC*/ MELT uses a lot of "varying size" structures. For example MELT objects are declared as typedef union melt_un *melt_ptr_t; typedef struct meltobject_st *meltobject_ptr_t; struct GTY ((variable_size)) meltobject_st { /* for objects, the discriminant is their class */ meltobject_ptr_t obj_class; unsigned obj_hash; /* hash code of the object */ unsigned short obj_num; /* discriminate the melt_un containing it as discr */ #define object_magic obj_num unsigned short obj_len; melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM]; }; A small but annoying issue is that GCC 4.5's gengtype does not accept the variable_size annotation, and I would want to have it ignore it. As far as I know, gengtype don't like CPP conditionals; what I really want is something like: #if MELT_HAS_TYPED_GGC_ALLOC struct GTY ((variable_size)) #else struct GTY (()) #endif meltobject_st { /* for objects, the discriminant is their class */ meltobject_ptr_t obj_class; unsigned obj_hash; /* hash code of the object */ unsigned short obj_num; /* discriminate the melt_un containing it as discr */ #define object_magic obj_num unsigned short obj_len; melt_ptr_t GTY ((length ("%h.obj_len"))) obj_vartab[FLEXIBLE_DIM]; }; But I am not sure it would work. What is the status of gengtype with respect to preprocessor conditionals? A possible hack for that would be to change in GCC 4.5.1 gengtype the error build/gengtype /usr/src/Lang/basile-melt-gcc/gcc gtyp-input.list /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: unknown option `variable_size' to a warning, perhaps specific to variable_size, something like /usr/src/Lang/basile-melt-gcc/gcc/melt-runtime.h:431: warning: `variable_size' is ignored Is that possible, or is GCC 4.5.1 gengtype code frozen for every 4.5.x? Other comments are welcome. Cheers. PS. I think this discussion is of general interest, because I could imagine that some plugins will try hard to be compilable & used both on gcc 4.5 & gcc 4.6. Of course, we cannot guarantee that it is doable in the general case. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
