This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |