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]

Re: Progress on GCC plugins ?


Joe Buck <Joe.Buck@synopsys.COM> writes:

> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
> > Is there any progress in the gcc-plugin project ?
> 
> Non-technical holdups.  RMS is worried that this will make it too easy
> to integrate proprietary code directly with GCC.
> 
> If proponents can come up with good arguments about how the plugin
> project can be structured to avoid this risk, that would help.

It seems very likely that it would be possible to write a plugin which
would generate IR to be fed into a proprietary backend.  Sun's GCCfss
is an existing example of what could be done in this area.  Of course,
GCCfss also shows that if people want to do this, they will.  Adding a
plugin framework doesn't even make it notably easier.  Once you've
written code to translate GIMPLE into some other IR, dropping it into
gcc is a matter of changing a few lines.  Providing a plugin interface
is not the issue.

More deeply, I think his concern is misplaced.  I think that gcc has
already demonstrated that the only widely used compilers are free
software.  Proprietary compilers don't keep up over time, outside of
niche markets.  Hooking proprietary code into gcc, one way or another,
is just going to create a dead end for the people who do it.
Certainly it's not a good thing, and certainly it would be preferable
to prevent it if possible.  But it is not the worst possible thing
that could happen; it is merely a cost.

I won't enumerate the benefits of plugins here.  But it is clear to me
that the benefits outweigh the costs.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]