GSOC - Student Rondup
Hey all, I was talking on IRC the other day with others and we thought this would be a nice idea, to ask all GSOC students how were all getting on working within GCC. As i am sure you have noticed GCC is a pretty big piece of code and it can be hard to get to grips with it all. I am kind of lucky because i was on GSOC last year and spent most of the summer if not all just getting comfortable with it. So i thought we could use this as a thread to introduce us a students to each other I'll go first! My name is Philip Herron I'm from Ireland and i got inspired by Paul Biggars work into PHC http://www.phpcompiler.org/ to implement a python front-end to gcc. Its hard but just something i find interesting more than anything. I'm am getting on quite well with my project, spent last week after the GCC meet-up in London cleaning up my IL and now i am implementing my own pass system as i have to iterate several passes over my IL (for various reasons) before i generate GENERIC. As i was on GCC last year i thought i would share things i found to be helpful when you encounter a problem: 1 - Work at it for max 1 day on your own but definitely try to join our irc on irc.oftc.net #gcc and ask. If you still find no help send a mail to gcc-help 2 - gcc -save-temps can be helpful now and again when working with alot of macros 3 - ack-grep is very helpful: http://betterthangrep.com/ makes searching though code much easier than learning to use grep properly :P 4 - Don't be afraid to ask questions as often as possible on irc and to your mentor I've bugged my mentor Ian with alot of really stupid small things all the time :) but they don't bite. And just finally i thought i would ask what aspects have you found within gcc hard to get to grips with if at all, it could be interesting to see if there is any correlation between areas. Personally i found getting to grips with Makefiles properly was hard i used to rely on automake for everything before. And learning to figure out how to use the generic tree api was confusing but in the end its very simple. We've found not all students are on irc its a really great platform to ask questions very informally its worth getting used to you can use web clients like mibbet irc or firefox extensions, i use irssi but those clients are much more friendly. Hope everyone's project is going well and your comfortable or getting more comfortable with what your doing! :) Happy Coding! --Phil PS: what do you think of the idea if we have a thread like this every few weeks or sooner (maybe on irc)? Just to see if we can help each other etc?
Re: nested switch optimization
On Wed, Jun 29, 2011 at 9:14 PM, Ian Lance Taylor wrote: > "Marcin J." writes: > >> will be possible to add optimization that merge this two (or more) switch in >> one big one (even if inner one is from inline function?) and then use one >> jump table for both switches? > > Is it possible? Sure. It's quite a special case, though, so if it's > enabled by default it would have to be really fast. Fortunately it's > easy to find switch statements as they will be the last statement in a > basic block. See gcc/tree-switch-conversion.c for ideas on how to > approach this. I think even cfgcleanup could do this merging if the switch indexes are literally the same and the default case block only contains the nested switch stmt. Richard. > Ian >
Re: [google] Merged gcc-4_6-branch -> google/gcc-4_6
On Wed, Jun 29, 2011 at 12:31, Ollie Wild wrote: > Diego will merge this to the google/gcc-4_6 branch. Done. Diego.
MELT is finding simple bugs in melt-runtime.c!
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 (,)
This is a quite big C macro. The is a constant giving the
number of MELT local pointers in this routine. The 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
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: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
gcc-4.5-20110630 is now available
Snapshot gcc-4.5-20110630 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110630/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 175733 You'll find: gcc-4.5-20110630.tar.bz2 Complete GCC MD5=fc867b8767f9a088d5cfa1bc8d9bde5d SHA1=994d8db12377a8559d1ac2d2f621e54f39a4c87f Diffs from 4.5-20110623 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
