Quoting Richard Guenther <richard.guent...@gmail.com>:
It's not that simple if you are not suggesting that all plugin development will happen against a stable branch. And even then the plugin binary needs an exactly mathching gcc version - how do you suppose the user will get that? By compiling both itself or by the developer being a distributor of binary gcc versions alongside his plugin?
No, rather the developer would back-port the plugin to the release version. Assuming (s)he is motivated enough to do that in order to get feedback. For the binary to match, it should be enough for it to be for the exact release version and a matching target architecture and object file format. The operating system should only matter if the plugin itself uses system functions, or if there are differences in the dynamic library format - the latter might be overcome with a final linking step on the host system. With a good plugin interface, backporting should be less painful than back-porting patches: When you add something to a list with a patch, it breaks when anything else got added / removed. If something is added with a plugin hook, you are isolated from such textual conflicts both in the main gcc codebase as well as from other plugins.
Note that with the same reasoning the developer could provide patches against a released gcc instead of just gcc trunk.
Not only are there likely more textual conflicts for the developer to fix, patches are not so easy to use by the user, so fewer people will volunteer to be ginea pigs for experimental GCC changes. Moreover, plugins should generally stack well, so we could see interesting feedback about combining plugins. multiple patches that affect the same areas of the compiler can often not be combined by a user.
