This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new plugin events
On Fri, 6 Nov 2009, Richard Guenther wrote:
> its internal symbols are to be exported), they reduce the value of
> the FSF GCC version because it lacks features only available as plugin.
That's why I think it's important for people to consider carefully in each
case whether a plugin or integration in GCC is the right way to implement
a given feature. I think of plugins as being for GCC features (warnings,
optimizations, etc.) only relevant for compiling some piece of software or
using some library, for example, and not generally relevant to standard
code in the relevant source language. They are not generally appropriate
for optimizations relying only on standard language or library features,
for example.
There are cases where the expected instability of the plugin API can be a
*feature*. For example, people have wanted ways for -Wformat to check
custom types of format strings, but there's never been a design I've been
happy with in terms of both sufficient flexibility and not exporting too
much implementation internals that we might wish to change in future. I'd
be much happier there with a few plugin hooks that expose all the format
checking datastructures, and an understanding that these will change or
break when those structures change, than with directly exposing all those
structures to user source code as part of the GNU C and C++ languages.
(Making the checking for GCC-internal formats into such a plugin has been
suggested in the past, and is not completely unreasonable.)
--
Joseph S. Myers
joseph@codesourcery.com