Re: GSOC - Student Roundup

[Pierre Vittet <piervit@pvittet.com>]

Hi,

I am Pierre Vittet, one of the GSOC students. I am writing a plugin 
which is a simple statical analysis tools. The idea is to write some 
tests (like testing that a function call is tested to return somethings 
(not) null, or testing that a call to a given function is followed by a 
call to another function.), that can be parametrized by the user (to be 
run on the functions he wants to check). I feel it can be a useful tool 
(however I am ready to fight with false positives).

I am using MELT (http://gcc-melt.org/) for this, I know that is quite a 
hot topic in the community and it is not much considered. MELT aims at 
abstracting GCC internal with a higher level language. I think that it 
can be a good way to enter into GCC, because it permits to parse quite 
quikly the GCC internal, gimple especially. The major feature of MELT is 
his pattern matching on tree ability.

Part of my work is to improve MELT (as I need some features which were 
not implemented), such as having handling pragma in MELT plugins or 
gluing some GCC dominance functions (from gcc/dominance.c)

However, like the others students which answered to this thread, the 
main difficulty is understanding and eventually modifying GCC itself. 
That is quite time consumming, as you can have, even to write a simple 
patch, to know well several parts of GCC (I am often grepping for a 
given struct or function). I also thing that each pass could be more 
detailled. Sometimes, it is hard to find a pass in the code from it's 
dump file name.

I had to write a patch for the trunk, to add a data field to pragma 
handlers, this was quite a simple patch, however, I had to make it 
compatible with the fact that one of the function I was modifying was 
used many times in differents parts of GCC.

Currently, I need to understand how works C++ mangling if I want my 
plugin to work with C++ (I am going to write a new mail about this), as 
I need to convert the string given by the user into the function(s) that 
it represents.

About the state of my plugin, I have written the core of the module.
It can use user's input from different entries (I have already written 
an entrie using the pragma, and an entrie using direct argument (given 
when invoking GCC), searchs if it matchs a corresponding test and 
generate a new GCC Pass from this. This new pass is inserted after ssa 
pass, as I got a representation which suits to me (I can find the 
information my tests need). But the choice of inserting here is quite 
empirical (would have you choice another pass?). The plugin is mainly 
tested for C code, even if I would like to have C++ working too.

I have started implementing tests, for the moment I use a test which 
checks that there is a test checking for a NULL pointer (if resCall == 
NULL for exemple) after a given function call, and return a warning if 
there is no test.

I have also started implementing a test checking that a given is 
immediatly followed by another given function. I would also try to add a 
test checking that a call to a given function is followed by a call to 
another function in the same function bodies, I know that I will have to 
handle the basic block hierarchie, that why I glued dominance functions 
into MELT.

I think, I am in time, however, this is sometimes hard to evaluate: for 
exemple, I don't know really how much time, I will take to manage C++ 
function in my plugin.

I feel sad, not being able to use IRC from my web access (in my 
school)... and so only communicating by mail with the GCC community. 
However, I thanks the community for their answer and support. The point 
to improve, I guess, is having more people reviewing patchs (even if, I 
understand that it requires a lot of time and skills).

Thanks

Pierre Vittet


On 05/07/2011 21:08, Daniel Carrera wrote:
> Hello Philip + Dimitrios
>
> Thanks for your posts. I am another GSOC student. I am working on the
> Fortran front-end of GCC (gfortran). Like most GFortran developers, my
> background is more in the natural sciences (astrophysics in my case)
> rather than computer science.
>
> My project is to help add coarray support for GFortran. Coarrays are a
> cool new feature in the Fortran 2008 standard that give Fortran native
> support for parallel programming (as opposed to using MPI or OpenMP).
> Scientific simulations (especially in parallel clusters) are the bread
> and butter of Fortran.
>
>
> Learning how GCC works has been difficult but rewarding. My work is
> split between the libgfortran library, which is straight forward enough,
> and the Fortran front-end, which at first looked like gobbledygook.
> Today I can actually understand most front-end functions when I read
> them, but it took a long time to get to this point. GCC has a scary
> learning curve.
>
> The libgfortran library is more forgiving for the beginner. We are using
> MPI as the backend to implement coarrays and I have very much enjoyed
> learning MPI.
>
> So far my contributions have been modest, but now that I've crossed much
> of the learning curve, I feel optimistic. To an extent the progress has
> to be a bit slow because we are looking at the new Fortran standard and
> thinking about the best way to add features.
>
> Cheers,
> Daniel.