Hi, Richard Guenther <richard.guent...@gmail.com> skribis:
> But no, I'm not volunteering (I'm volunteering to do the review work). > The above has the same issue as the "we-want-to-be-more-like-LLVM" > stuff - it lacks the people to actually implement it, and GCC at its > present state still has to evolve, we can't and do not want to just spend > a complete release or two with just turning GCC upside-down. What David proposes looks great, but also fairly intrusive and development-intensive. Perhaps a more incremental approach could be taken. For instance, I would argue that changes to the tree and GIMPLE APIs could be made conservatively, on the grounds that they are most likely used by plug-ins out there. IOW, rather than a commitment to a stable API, which would hinder the work of GCC developers, this would be an informal agreement to not make the plug-in developers life too hard. In the example of name mangling, I’d just have wrapped in ‘extern "C"’ all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in. The rationale is that it simplifies plug-in maintenance, while not impeding development work in 4.7. In the longer term, providing a GCC plug-in alongside one’s library or program should become as natural as providing a syntax highlighting mode. Thanks, Ludo’.