I've posted two patches implementing a GIMPLE Frontend to the extent required for simple unit testing of GIMPLE passes. The work was mostly done by Prasad Ghangal during this years GSoC project. I've picked it up to ensure it would be ready for the end of stage1 even though the frontend itself can IMHO be developed throughout stage3 where required.
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02336.html https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02335.html The current status is that simple C testcases can be compiled and dumped at some random pass with -gimple and that dump output can be fed back into the GIMPLE frontend (by adding -fgimple to the C compiler invocation). Most syntax and semantic checking is only done by the GIMPLE verification code we have in the middle-end as the parser is modeled after the C one which usually accepts more complex input as allowed by GIMPLE. I expect there is syntax we still do not parse (MEM_REF comes to my mind) plus on-the-side info that we either do not have a good source representation for or that the parser does not yet parse (generally EH info or things like range info or points-to info). Currently what the parser emits is a mixed bag of low and high gimple (it's technically high gimple as it still has the outer gimple BIND). It parses SSA form with PHIs being represented as a function call to __PHI with pairs of label (comes-from) and value. A feature of the frontend is that it allows (or rather requires for all declarations) mixing C with GIMPLE. This means you can write a single function in GIMPLE and surround it with a (unit-)test harness written in C. I hope we can get this into GCC 7, kind of as a preview as I expect it will evolve once we get the first unit tests (I didn't try to re-write existing tests). Thanks, Richard.