Hello All, I just achieved an interesting milestone: a simple (and ad-hoc) MELT analysis pass which is actually finding some "bugs" (at least, some useless code) inside melt-runtime.c. Committed revision 175725. [on the MELT branch]
Actually, I did wrote that mostly as an exercise in MELT, and also to really eat my own dog food (is that the correct American expression to say that I am administrating myself the "food" -ie MELT- I want others to take?). Now, the gory details, in case you are interested. If you didn't hear of MELT, look at gcc-melt.org & http://lwn.net/Articles/447916/ (which also contains justified criticisms on GCC MELT). MELT is a plugin & a branch providing a domain specific language (lisp-like syntax, translated to C, with pattern matching) to code GCC extensions in. MELT has a runtime providing a copying generational garbage collector (for MELT values only) above the existing Gg-c. MELT GC requires some particular coding styles & conventions, in particular, each MELT routine hand-coded in C should start with MELT_ENTERFRAME (<number>,<closure>) This is a quite big C macro. The <number> is a constant giving the number of MELT local pointers in this routine. The <closure> is often null (when it is not null, it gives the current MELT closure). And that routine should end with MELT_EXITFRAME () which is a small macro. For example, here is (from melt-runtime.c line 1612 & following) a routine which boxes a long into a MELT boxed long value. ############################## our melt long boxing routine melt_ptr_t meltgc_new_int (meltobject_ptr_t discr_p, long num) { MELT_ENTERFRAME (2, NULL); #define newintv meltfram__.mcfr_varptr[0] #define discrv meltfram__.mcfr_varptr[1] #define object_discrv ((meltobject_ptr_t)(discrv)) #define int_newintv ((struct meltint_st*)(newintv)) discrv = (void *) discr_p; if (melt_magic_discr ((melt_ptr_t) (discrv)) != MELTOBMAG_OBJECT) goto end; if (object_discrv->meltobj_magic != MELTOBMAG_INT) goto end; newintv = meltgc_allocate (sizeof (struct meltint_st), 0); int_newintv->discr = object_discrv; int_newintv->val = num; end: MELT_EXITFRAME (); return (melt_ptr_t) newintv; #undef newintv #undef discrv #undef int_newintv #undef object_discrv } ############################# The initial MELT_ENTERFRAME (2, NULL) macro is expanded to something similar to ############################# the cpp expansion of MELT_ENTERFRAME struct { int mcfr_nbvar; const char *mcfr_flocs; struct meltclosure_st *mcfr_clos; struct excepth_melt_st *mcfr_exh; struct callframe_melt_st *mcfr_prev; void *mcfr_varptr[2]; } meltfram__; do { static char locbuf_1591[84]; if (!locbuf_1591[0]) snprintf (locbuf_1591, sizeof (locbuf_1591) - 1, "%s:%d", basename ("gcc/melt-runtime.c"), (int) 1591); memset (&meltfram__, 0, sizeof (meltfram__)); meltfram__.mcfr_nbvar = (2); meltfram__.mcfr_flocs = locbuf_1591; meltfram__.mcfr_prev = (struct callframe_melt_st *) melt_topframe; meltfram__.mcfr_clos = (((void *) 0)); melt_topframe = ((struct callframe_melt_st *) &meltfram__); } while (0); ############################# What the static analysis pass (called meltframe and provided in gcc/melt/xtramelt-ana-simple.melt, near lines 1286-1540 of the MELT branch) is a check that every slot in the mcfr_varptr field of the local meltfram__ variable is really used. Those slots that are not used are bogus, and the MELT_ENTERFRAME could have a smaller <number> argument. And indeed, this meltfram pass did find such small bugs in melt-runtime.c gcc/melt-runtime.c:7199:1: warning: MELT warning meltvarptr not used at index at 'meltgc_intern_keyword' - #1 [enabled by default] gcc/melt-runtime.c:7199:1: warning: MELT warning meltvarptr not assigned at index at 'meltgc_intern_keyword' - #1 [enabled by default] (BTW, I didn't use the def/use of vars as GCC compute it; I just scanned the gimple-s, and pattern matched the assignments) The next simple step is to correct these bugs. Cheers. ##### French summary (for the gcc-melt-french@ list which is in CC) J'ai codé une passe MELT qui trouve des bogues dans melt-runtime.c, notamment les éléments de meltvarptr qui sont inutiles. -- 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 mine, sont seulement les miennes} ***
