On Tue, Jun 15, 2010 at 11:26 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > 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?
Yes, gengtype is frozen for functional changes on the branch. > 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. And we specifically said this is not going to be possible. Richard.
