* Progress on GCC plugins ? @ 2007-11-07 8:37 Emmanuel Fleury 2007-11-07 16:47 ` Joe Buck 0 siblings, 1 reply; 108+ messages in thread From: Emmanuel Fleury @ 2007-11-07 8:37 UTC (permalink / raw) To: gcc Hi, Is there any progress in the gcc-plugin project ? How far is the code and what about its integration in a future release ? I still think this is a great idea and I'm quite impatient to try it out (I'll have some time in January). Regards -- Emmanuel Fleury Out the 10Base-T, through the router, down the T1, over the leased line, off the bridge, past the firewall...nothing but Net. -- Tony Miller ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 8:37 Progress on GCC plugins ? Emmanuel Fleury @ 2007-11-07 16:47 ` Joe Buck 2007-11-07 17:11 ` Basile STARYNKEVITCH ` (5 more replies) 0 siblings, 6 replies; 108+ messages in thread From: Joe Buck @ 2007-11-07 16:47 UTC (permalink / raw) To: Emmanuel Fleury; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck @ 2007-11-07 17:11 ` Basile STARYNKEVITCH 2007-11-07 17:20 ` Tom Tromey ` (4 subsequent siblings) 5 siblings, 0 replies; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-07 17:11 UTC (permalink / raw) To: Joe Buck; +Cc: Emmanuel Fleury, gcc Joe Buck wrote: > 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. I thought (from my memory and understanding of discussions at last GCC summit in July 2O07 in Ottawa) that a major argument against this risk is that there is no stability in the API offered by GCC to plugins. So any proprietary plugin would be a nightmare to maintain... -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck 2007-11-07 17:11 ` Basile STARYNKEVITCH @ 2007-11-07 17:20 ` Tom Tromey 2007-11-07 17:34 ` Robert Dewar 2007-11-07 17:49 ` Dave Korn ` (3 subsequent siblings) 5 siblings, 1 reply; 108+ messages in thread From: Tom Tromey @ 2007-11-07 17:20 UTC (permalink / raw) To: Joe Buck; +Cc: Emmanuel Fleury, gcc >>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.COM> writes: Joe> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote: >> Is there any progress in the gcc-plugin project ? Joe> Non-technical holdups. RMS is worried that this will make it too easy Joe> to integrate proprietary code directly with GCC. Joe> If proponents can come up with good arguments about how the plugin Joe> project can be structured to avoid this risk, that would help. First, aren't we already in this situation? There are at least 2 compilers out there that re-use parts of GCC by serializing trees and then reading them into a different back end. Second, how does the LTO project avoid this same worry? Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 17:20 ` Tom Tromey @ 2007-11-07 17:34 ` Robert Dewar 2007-11-07 17:47 ` Chris Lattner 2007-11-08 13:02 ` Florian Weimer 0 siblings, 2 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-07 17:34 UTC (permalink / raw) To: tromey; +Cc: Joe Buck, Emmanuel Fleury, gcc Tom Tromey wrote: > First, aren't we already in this situation? There are at least 2 > compilers out there that re-use parts of GCC by serializing trees and > then reading them into a different back end. It's not obvious to me that this is consistent with the GPL .. interesting issue ... > > Second, how does the LTO project avoid this same worry? > > Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 17:34 ` Robert Dewar @ 2007-11-07 17:47 ` Chris Lattner 2007-11-08 13:02 ` Florian Weimer 1 sibling, 0 replies; 108+ messages in thread From: Chris Lattner @ 2007-11-07 17:47 UTC (permalink / raw) To: Robert Dewar; +Cc: tromey, Joe Buck, Emmanuel Fleury, gcc On Nov 7, 2007, at 9:28 AM, Robert Dewar wrote: > Tom Tromey wrote: > >> First, aren't we already in this situation? There are at least 2 >> compilers out there that re-use parts of GCC by serializing trees and >> then reading them into a different back end. > > It's not obvious to me that this is consistent with the GPL .. > interesting issue ... Assuming these projects are "linking" it in, it just means the resulting compiler is also be GPL. That seems consistent. -Chris ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 17:34 ` Robert Dewar 2007-11-07 17:47 ` Chris Lattner @ 2007-11-08 13:02 ` Florian Weimer 2007-11-08 14:01 ` Robert Dewar 1 sibling, 1 reply; 108+ messages in thread From: Florian Weimer @ 2007-11-08 13:02 UTC (permalink / raw) To: Robert Dewar; +Cc: tromey, Joe Buck, Emmanuel Fleury, gcc * Robert Dewar: > Tom Tromey wrote: > >> First, aren't we already in this situation? There are at least 2 >> compilers out there that re-use parts of GCC by serializing trees and >> then reading them into a different back end. > > It's not obvious to me that this is consistent with the GPL .. It requires a fairly expansionist view of copyright to make it inconsistent. The FSF has made similar claims in the past (for instance, that all Emacs Lisp code must be GPLed), but I'm not convinced that arguing for more Draconian copyright laws helps the free software cause. Copyleft requires compromises in this area, of course, but some deals should be off limits. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-08 13:02 ` Florian Weimer @ 2007-11-08 14:01 ` Robert Dewar 0 siblings, 0 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-08 14:01 UTC (permalink / raw) To: Florian Weimer; +Cc: tromey, Joe Buck, Emmanuel Fleury, gcc Florian Weimer wrote: > * Robert Dewar: > >> Tom Tromey wrote: >> >>> First, aren't we already in this situation? There are at least 2 >>> compilers out there that re-use parts of GCC by serializing trees and >>> then reading them into a different back end. >> It's not obvious to me that this is consistent with the GPL .. > > It requires a fairly expansionist view of copyright to make it > inconsistent. I disagree (based significantly on the proceedings of the Intergraph vs Bentley trial, which unfortunately are not easily published anywhere), but I think this thread should not go too much farther here, it is really off topic. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck 2007-11-07 17:11 ` Basile STARYNKEVITCH 2007-11-07 17:20 ` Tom Tromey @ 2007-11-07 17:49 ` Dave Korn 2007-11-07 18:45 ` David Edelsohn 2007-11-08 0:10 ` Brendon Costa ` (2 subsequent siblings) 5 siblings, 1 reply; 108+ messages in thread From: Dave Korn @ 2007-11-07 17:49 UTC (permalink / raw) To: 'Joe Buck', 'Emmanuel Fleury'; +Cc: gcc On 07 November 2007 16:41, Joe Buck wrote: > 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. I don't understand: why wouldn't designing it so that they have to be implemented as DSOs and hence are covered by the anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern that people will write trivial marshalling plugins and ship all the data out across a pipe or socket to some proprietary code and then only release source for their shim layers? cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 17:49 ` Dave Korn @ 2007-11-07 18:45 ` David Edelsohn 2007-11-07 19:11 ` Robert Dewar 2007-11-08 12:57 ` Dave Korn 0 siblings, 2 replies; 108+ messages in thread From: David Edelsohn @ 2007-11-07 18:45 UTC (permalink / raw) To: Dave Korn; +Cc: 'Joe Buck', 'Emmanuel Fleury', gcc >>>>> Dave Korn writes: Dave> I don't understand: why wouldn't designing it so that they have to be Dave> implemented as DSOs and hence are covered by the Dave> anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern Dave> that people will write trivial marshalling plugins and ship all the data out Dave> across a pipe or socket to some proprietary code and then only release source Dave> for their shim layers? The concern is the many forms of shim layers that possibly could be written more easily with a plug-in framework. David ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 18:45 ` David Edelsohn @ 2007-11-07 19:11 ` Robert Dewar 2007-11-07 21:55 ` Brendon Costa 2007-11-08 12:57 ` Dave Korn 1 sibling, 1 reply; 108+ messages in thread From: Robert Dewar @ 2007-11-07 19:11 UTC (permalink / raw) To: David Edelsohn Cc: Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc David Edelsohn wrote: >>>>>> Dave Korn writes: > > Dave> I don't understand: why wouldn't designing it so that they have to be > Dave> implemented as DSOs and hence are covered by the > Dave> anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern > Dave> that people will write trivial marshalling plugins and ship all the data out > Dave> across a pipe or socket to some proprietary code and then only release source > Dave> for their shim layers? > > The concern is the many forms of shim layers that possibly could > be written more easily with a plug-in framework. there is also a difference in these two scenarios: 1. a) Company X writes a modification to GCC to generate special intermediate stuff with format Y. b) Company X writes propietary back end which can only read format Y stuff written by that modification. 2. Same as 1, except that the GCC project does step a) thus semi-standardizing the output. TO me it is pretty clear that these are very different situations from a license point of view. > > David ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 19:11 ` Robert Dewar @ 2007-11-07 21:55 ` Brendon Costa 2007-11-07 22:32 ` Robert Dewar 0 siblings, 1 reply; 108+ messages in thread From: Brendon Costa @ 2007-11-07 21:55 UTC (permalink / raw) To: Robert Dewar Cc: David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc >> The concern is the many forms of shim layers that possibly could >> be written more easily with a plug-in framework. > > there is also a difference in these two scenarios: > > 1. a) Company X writes a modification to GCC to generate special > intermediate stuff with format Y. > > b) Company X writes propietary back end which can only > read format Y stuff written by that modification. > > 2. Same as 1, except that the GCC project does step a) > thus semi-standardizing the output. > > TO me it is pretty clear that these are very different > situations from a license point of view. I do exactly point 1 for my (Open Source) C++ exception static analysis tool: http://edoc.sourceforge.net/ I need a subset of the data in a format that is easy for me to process and it must stay around for a long period of time so i dont want all the information that GCC could generate in a more generic form. So in this case i feel a non-standardized format is best suited for my project. This same argument would apply for other projects too, though i can see how it can be helpful to have a single more generic format. It just might not be suitable in a lot of cases. If you already have a plugin distributed with GCC that writes in a generic format, then most people will use that anyway if they can, rather than write and maintain their own plugin. This is a problem with or without the plugin framework. By adding plugins you have the same issues as before but just make it easier for all developers whether open source or proprietary to develop new GCC functionality. My project is an example of using a patch against GCC in order to achieve the "shim layer". I would much prefer to do this with a plugin, but a lack of the plugin framework is not going to stop me doing it whatever way i can. Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 21:55 ` Brendon Costa @ 2007-11-07 22:32 ` Robert Dewar 2007-11-07 22:43 ` Brendon Costa 0 siblings, 1 reply; 108+ messages in thread From: Robert Dewar @ 2007-11-07 22:32 UTC (permalink / raw) To: Brendon Costa Cc: David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc Brendon Costa wrote: >>> The concern is the many forms of shim layers that possibly could >>> be written more easily with a plug-in framework. >> there is also a difference in these two scenarios: >> >> 1. a) Company X writes a modification to GCC to generate special >> intermediate stuff with format Y. >> >> b) Company X writes propietary back end which can only >> read format Y stuff written by that modification. >> >> 2. Same as 1, except that the GCC project does step a) >> thus semi-standardizing the output. >> >> TO me it is pretty clear that these are very different >> situations from a license point of view. > > I do exactly point 1 for my (Open Source) C++ exception static analysis > tool: > http://edoc.sourceforge.net/ Well assuming that your tool is GPL'ed there is no issue and this is not a case of 1 above! ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 22:32 ` Robert Dewar @ 2007-11-07 22:43 ` Brendon Costa 2007-11-07 22:57 ` Robert Dewar 0 siblings, 1 reply; 108+ messages in thread From: Brendon Costa @ 2007-11-07 22:43 UTC (permalink / raw) To: Robert Dewar Cc: Brendon Costa, David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc Robert Dewar wrote: > Brendon Costa wrote: >>>> The concern is the many forms of shim layers that possibly could >>>> be written more easily with a plug-in framework. >>> there is also a difference in these two scenarios: >>> >>> 1. a) Company X writes a modification to GCC to generate special >>> intermediate stuff with format Y. >>> >>> b) Company X writes propietary back end which can only >>> read format Y stuff written by that modification. >>> >>> 2. Same as 1, except that the GCC project does step a) >>> thus semi-standardizing the output. >>> >>> TO me it is pretty clear that these are very different >>> situations from a license point of view. >> >> I do exactly point 1 for my (Open Source) C++ exception static analysis >> tool: >> http://edoc.sourceforge.net/ > > Well assuming that your tool is GPL'ed there is no issue and > this is not a case of 1 above! > The patch against GCC is GPL, the main library that is capable of manipulating the data exported by the patched GCC is LGPL and could theoretically be under any license. What i was trying to point out is that proprietary projects can already (without plugins) make exporters for GCC which are GPL and then create the majority of their code in other closed source apps that use that data. I don't see plugins as changing this except to make it easier. Which is really a major reason for proving plugins isn't it? Making it easier to provide additional GCC features? My project was given as an example of how it could be done currently without plugins even though this project is open source. Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 22:43 ` Brendon Costa @ 2007-11-07 22:57 ` Robert Dewar 2007-11-07 23:43 ` David Edelsohn 2007-11-07 23:44 ` Brendon Costa 0 siblings, 2 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-07 22:57 UTC (permalink / raw) To: Brendon Costa Cc: Brendon Costa, David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc Brendon Costa wrote: > The patch against GCC is GPL, the main library that is capable of > manipulating the data exported by the patched GCC is LGPL and could > theoretically be under any license. Whose theory? You don't know that! > > What i was trying to point out is that proprietary projects can > already (without plugins) make exporters for GCC which are GPL and > then create the majority of their code in other closed source apps > that use that data. You don't know that! > > I don't see plugins as changing this except to make it easier. Which > is really a major reason for proving plugins isn't it? Making it > easier to provide additional GCC features? No, it has other changes, since it establishes a standardized interface. In my view (from the point of view of an expert witness in copyright matters), this *does* make a big difference from a licensing point of view. Of course that's just my view, I don't know either, but I know that I don't know :-) > > My project was given as an example of how it could be done currently > without plugins even though this project is open source. The issue is not can it be done, but what are the licensing issues? And without litigation, no one really knows. > > Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 22:57 ` Robert Dewar @ 2007-11-07 23:43 ` David Edelsohn 2007-11-08 0:00 ` Brendon Costa 2007-11-07 23:44 ` Brendon Costa 1 sibling, 1 reply; 108+ messages in thread From: David Edelsohn @ 2007-11-07 23:43 UTC (permalink / raw) To: Robert Dewar Cc: Brendon Costa, Brendon Costa, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc If you want to have a legal discussion, please take this conversation somewhere else. Thanks, David ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 23:43 ` David Edelsohn @ 2007-11-08 0:00 ` Brendon Costa 0 siblings, 0 replies; 108+ messages in thread From: Brendon Costa @ 2007-11-08 0:00 UTC (permalink / raw) To: David Edelsohn Cc: Robert Dewar, Brendon Costa, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc David Edelsohn wrote: > If you want to have a legal discussion, please take this > conversation somewhere else. > > Thanks, David > Sorry. I just posted another email before i got this. Is there a suitable place to move this discussion besides private emails? Thanks, Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 22:57 ` Robert Dewar 2007-11-07 23:43 ` David Edelsohn @ 2007-11-07 23:44 ` Brendon Costa 2007-11-25 0:02 ` Alexandre Oliva 1 sibling, 1 reply; 108+ messages in thread From: Brendon Costa @ 2007-11-07 23:44 UTC (permalink / raw) To: Robert Dewar Cc: Brendon Costa, David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc Robert Dewar wrote: > Brendon Costa wrote: > >> The patch against GCC is GPL, the main library that is capable of >> manipulating the data exported by the patched GCC is LGPL and could >> theoretically be under any license. > > Whose theory? You don't know that! I thought it was obvious :-) My Theory... A theory is not necessarily true... I will clarify where i am coming from... I am a software developer and know very little about the legal side of things. What i have said is really the way i understand things as i have tried ti have a basic idea of what all this entails and how it affects my work. If the license extends to the data generated by GPL apps (Which is really what I think we are talking about), then wouldn't the binaries or for that matter the intermediate source files generated by GCC (for example using g++ -save-temps) also be covered under the GPL regardless of the license of the source being compiled? This data could include: * object files * intermediate source files (.i, .s) * pre-compiled header files * any other form of the original source serialized into some specific format such as GIMPLE exports etc. The problem with this is that each of these is really just a different representation of the original source code. This complicates matters even more if we have both the GPL of GCC and the license of the original source code impacting on what is generated. Wouldn't it mean that only certain types of licensed source code are allowed to be compiled with GCC? Where do you draw the limit of what is covered and what is not? It seems to me from what you have said, nothing is safe from the GPL. If an OS like BSD compiles itself with GCC and this mandates that anything which uses that data must also be licensed under GPL, then they have no choice but to say only GPL code is allowed to run on this OS. I dont see that as being the current common view. Most of the BSD's have a non-GPL license and still use GCC to compile. Or are you saying that the FORMAT of the data exported is covered by GPL, not the data itself? Does that mean if you design a particular data format in a GPL app, that you are not allowed to write a non-GPL application that uses data in that format? Does this also apply the other way around? I dont know if microsoft have some sort of license over the PExe formation for binaries. But if so, then is GCC actually ALLOWED to export data in that format? Look at GIF. Then i guess it is worth asking, does the GPL applied to the code of the plugin automatically then apply to the format of the data exported? Sorry for the long email. I am just trying to understand the issues involved. >> >> I don't see plugins as changing this except to make it easier. Which >> is really a major reason for proving plugins isn't it? Making it >> easier to provide additional GCC features? > > No, it has other changes, since it establishes a standardized > interface. In my view (from the point of view of an expert > witness in copyright matters), this *does* make a big difference > from a licensing point of view. Of course that's just my view, > I don't know either, but I know that I don't know :-) Are we talking about the standardized interface provided by GCC that people can use to write plugins for? If so i would agree that anything which uses this interface must be GPL. So the code for a plugin of GCC must also be GPL. If talking about the "interface" that is generated by the export of data in a particular format. I still dont see how that affects the tools that make use of that data format unless the particular format has a license imposed on it. Again, this is all just my view and I am *NOT* an expert in this field. In fact, i have had almost NO experience in legal areas. I am curious to know where i have mis-understood the application of the GPL to the GCC project and how that might apply to others like my EDoc++ project. Thanks, Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 23:44 ` Brendon Costa @ 2007-11-25 0:02 ` Alexandre Oliva 2007-11-25 17:15 ` Richard Kenner 0 siblings, 1 reply; 108+ messages in thread From: Alexandre Oliva @ 2007-11-25 0:02 UTC (permalink / raw) To: Brendon Costa Cc: Robert Dewar, Brendon Costa, David Edelsohn, Dave Korn, 'Joe Buck', 'Emmanuel Fleury', gcc On Nov 7, 2007, Brendon Costa <bcosta@avdat.com.au> wrote: > If the license extends to the data generated by GPL apps It doesn't, AFAIK, but IANAL. But the issue is not so much the specific data, but the format in which the data is and the reasons behind choosing that format. The FSF might successfully present to a court an argument such as: Look, Your Honor, it is quite obvious that the code in question was developed to work as a single program, and that the separation through the intermedia representation layer is just an attempt to escape the conditions of the license of the program they based their work on. Please don't permit the defendant to keep on distributing that code without complying with the license conditions. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-25 0:02 ` Alexandre Oliva @ 2007-11-25 17:15 ` Richard Kenner 0 siblings, 0 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-25 17:15 UTC (permalink / raw) To: aoliva; +Cc: Joe.Buck, bcosta, brendon, dave.korn, dewar, dje, fleury, gcc > The FSF might successfully present to a court an argument such as: > > Look, Your Honor, it is quite obvious that the code in question was > developed to work as a single program, and that the separation > through the intermedia representation layer is just an attempt to > escape the conditions of the license of the program they based their > work on. Please don't permit the defendant to keep on distributing > that code without complying with the license conditions. Yes, such an argument might be successful and indeed many people, including myself, believe it *likely* would be successful, but going to court is in many way a "crap shoot" and it might *not* be successful. If that happened it would set a precedent that could be extended on in a way that would be harmful to Free Software. That's why it's considered far better to try to avoid such a case in the first place. Moreover, if we did this in conjunction with a carefully-defined API, the defendant could argue that the purpose of that API was precisely to *not* have it be viewed as a single program, so the result of such a case would be far less certain. As was pointed out here numerous times, 90+% of the difficulty in working with is the difficulty in understanding the inherently-complex algorithmic structure of the compiler and its data structures (no real-world compiler will ever be able to use algorithms unmodified from a textbook) coupled with limited documentation. Doing something to make the remaining few percent easier will not, in my opinion, increase the participation in GCC enough to justify the legal risk to Free Software. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-07 18:45 ` David Edelsohn 2007-11-07 19:11 ` Robert Dewar @ 2007-11-08 12:57 ` Dave Korn 1 sibling, 0 replies; 108+ messages in thread From: Dave Korn @ 2007-11-08 12:57 UTC (permalink / raw) To: 'David Edelsohn' Cc: 'Joe Buck', 'Emmanuel Fleury', gcc On 07 November 2007 17:52, David Edelsohn wrote: > > The concern is the many forms of shim layers that possibly could > be written more easily with a plug-in framework. I wonder if we could adapt some kind of privsep model, so that once the compiler has finished init, it gives away its rights and can't even open files or create pipes or sockets any more. The gcc.c driver could remain at full user prives and take care of opening everything (a bit like I guess it already does when you're using -pipe?) and cc1 and pals could all be hobbled. Ooooor..... how about we define plugins in an interpreted or bytecoded language and don't allow any IO whatsoever? Oooooorrrr.... if we were really clever we could maybe define an interface that's entirely non-enumerable: it calls out to hooks, providing them with just enough information and interfaces to do the job they have to do, but we don't make it possible to derive information about the overall AST because we don't provide any way to know 'what's out there'. #1 seems like there might too easily be loopholes even assuming it can actually be made to work, that is to say that it would be very hard to really prevent data escaping from the process boundary using the unix fs perms model. Maybe the more modern unices with finergrained acls and kernel object permissions would be able to make work, but I think that the lesson of chroot jails is that they're to prevent fat-finger errors, not determined security attackers. #3 isn't necessarily possible either. It would probably need serious maths formalisms and proofs to define. Zero-knowledge secret problem sharing based plugins, anyone? #2 might well be a goer. It looks pretty plausible. cheers, DaveK [carefully avoiding the IANAL debate :-)] -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck ` (2 preceding siblings ...) 2007-11-07 17:49 ` Dave Korn @ 2007-11-08 0:10 ` Brendon Costa 2007-11-08 7:21 ` Ian Lance Taylor 2007-11-15 21:43 ` Diego Novillo 5 siblings, 0 replies; 108+ messages in thread From: Brendon Costa @ 2007-11-08 0:10 UTC (permalink / raw) To: Joe Buck; +Cc: Emmanuel Fleury, gcc Joe Buck wrote: > 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. > Is there anything that still needs to be done on the technical side at all like testing or development? I am willing to help out a bit. I have an interest in seeing this in a future release :-) Thanks, Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck ` (3 preceding siblings ...) 2007-11-08 0:10 ` Brendon Costa @ 2007-11-08 7:21 ` Ian Lance Taylor 2007-11-08 10:23 ` Emmanuel Fleury 2007-11-08 20:51 ` Mark Mitchell 2007-11-15 21:43 ` Diego Novillo 5 siblings, 2 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-08 7:21 UTC (permalink / raw) To: Joe Buck; +Cc: Emmanuel Fleury, gcc 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-08 7:21 ` Ian Lance Taylor @ 2007-11-08 10:23 ` Emmanuel Fleury 2007-11-08 20:51 ` Mark Mitchell 1 sibling, 0 replies; 108+ messages in thread From: Emmanuel Fleury @ 2007-11-08 10:23 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Joe Buck, gcc Ian Lance Taylor wrote: > > 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. I won't add anything to the comments of Ian because I fully agree with him but I would like to clarify what I expect from GCC. First of all, I'm coming from the verification community and I'm currently very interested in '(automatic) code verification'. What our community is really seeking for by now is a tool aiming at providing an abstract (i.e. simplified) model of program sources. And actually, GCC do it internally. Indeed, you can provide a gimplified CFG of C, C++, Java, ... source files and many other informations, which overpass tools such as CIL (C Intermediate Language, http://manju.cs.berkeley.edu/cil/) because of the numerous front-end of GCC. What I would like to have is just some mean to extract the last step before the translation into RTL (usually 'final_cleanup'). Surely, having the possibility to decorate the code with some extra information would be something more but we can actually work-around without any problem considering the benefits we get from not having to maintain all the front-ends. What is providing the 'plugin scheme' is actually much more than we need because it goes deep inside GCC and allow *modification* of GCC internals (and therefore might break a lot of things, I guess) which (in my humble opinion) is the real problem here. Maybe defining some standardized outputs (very similar to -fdump-tree-*) targeted for static-analysis and model-checking tools would be enough as the main problem for us is just to get GCC to export its intermediate internal representations of the program in a way which is reliable and stable from one version to another. For the software I'm thinking of I really just need the final CFG and maybe a summary of the IPA would help as well. Regards -- Emmanuel Fleury If you don't get everything you want, think of the things you don't get that you don't want. -- Oscar Wilde ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-08 7:21 ` Ian Lance Taylor 2007-11-08 10:23 ` Emmanuel Fleury @ 2007-11-08 20:51 ` Mark Mitchell 2007-11-09 18:12 ` Gerald.Williams 1 sibling, 1 reply; 108+ messages in thread From: Mark Mitchell @ 2007-11-08 20:51 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Joe Buck, Emmanuel Fleury, gcc Ian Lance Taylor wrote: > It seems very likely that it would be possible to write a plugin which > would generate IR to be fed into a proprietary backend. > > More deeply, I think his concern is misplaced. For the record, I agree on both points. There are some ways in which plugins might make getting proprietary code in the loop easier. For example, if someone plugs Guile into the plugin interface, then it might be easy to write a pile of LISP code to poke at GCC. I understand that there are differing opinions on whether or not these kinds of indirections affect the GPL. But, that's the kind of thing that the FSF gets to think about. But, as you say, the whole idea of the GPL is that people can go build what they want -- including plugin frameworks to GCC that might or might not allow them to interface with proprietary code. If it's really worth it to them, then they will. The FSF's best defense is to make it not worth it by providing enough valuable free software. Anyhow, in practical terms, debating this here probably will have zero impact on the outcome. The ball is in RMS' court, and SC members (including myself) have made many of the arguments that have been made in this thread. If people want to influence the FSF, the best approach is probably going to be sending mail directly to RMS, not discussing it on this list. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-08 20:51 ` Mark Mitchell @ 2007-11-09 18:12 ` Gerald.Williams 0 siblings, 0 replies; 108+ messages in thread From: Gerald.Williams @ 2007-11-09 18:12 UTC (permalink / raw) To: gcc Mark Mitchell wrote: > Anyhow, in practical terms, debating this here probably will have zero > impact on the outcome. The ball is in RMS' court, and SC members > (including myself) have made many of the arguments that have been made > in this thread. If people want to influence the FSF, the best approach > is probably going to be sending mail directly to RMS, not discussing it > on this list. I think your opinion probably carries a bit more weight with RMS than mine. :-) I don't want to prolong a pointless discussion either, but I hope somebody has made the "forest through the trees" argument. Proprietary extensions using a standard plug-in interface will eventually get replaced by free ones if they're of value. In the long term, this type of direct assault on GPL would backfire in a big way. -Jerry ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-07 16:47 ` Joe Buck ` (4 preceding siblings ...) 2007-11-08 7:21 ` Ian Lance Taylor @ 2007-11-15 21:43 ` Diego Novillo 2007-11-15 21:46 ` Joe Buck 2007-11-15 21:53 ` Richard Kenner 5 siblings, 2 replies; 108+ messages in thread From: Diego Novillo @ 2007-11-15 21:43 UTC (permalink / raw) To: Joe Buck; +Cc: Emmanuel Fleury, gcc Joe Buck wrote: > 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. I don't believe this is a strong argument. My contention is, and has always been, that GCC is _already_ trivial to integrate into a proprietary compiler. There is at least one compiler I know that does this. In fact, much/most of the effort we have been spending in making GCC easier to maintain, necessarily translates into a system that is easier to integrate into other code bases. IMO, the benefits we gain in making GCC a more attractive code base, far outweigh the fears of someone co-opting it for their own proprietary uses. We gain nothing by holding infrastructure advances in GCC. While GCC still has the advantage of being widely used, its internal infrastructure is still relatively arcane and hard to deal with. We have already kicked it into the mid 90s, but we still have a lot of ground to cover. An antiquated and arcane infrastructure will only help turn new developers away. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 21:43 ` Diego Novillo @ 2007-11-15 21:46 ` Joe Buck 2007-11-15 21:53 ` Richard Kenner 1 sibling, 0 replies; 108+ messages in thread From: Joe Buck @ 2007-11-15 21:46 UTC (permalink / raw) To: Diego Novillo; +Cc: Emmanuel Fleury, gcc On Thu, Nov 15, 2007 at 02:34:38PM -0500, Diego Novillo wrote: > Joe Buck wrote: > >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. > > I don't believe this is a strong argument. My contention is, and has > always been, that GCC is _already_ trivial to integrate into a > proprietary compiler. There is at least one compiler I know that does this. I agree, but we still have the roadblock. Maybe we need a group of volunteers to meet with RMS in person and work on convincing him. E-mail seems way too inefficient and frustrating a mechanism. RMS regularly points to the examples of C++ and Objective-C as an argument for trying to force all extensions to be GPL (Mike Tiemann's employer tried to figure out a way of making g++ proprietary; NeXT tried a "user does the link" hack to get around the GPL for their original Objective-C compiler). Problem is, he hasn't really kept up; the problem with being as pure as he is is that you can become isolated from what's going on. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 21:43 ` Diego Novillo 2007-11-15 21:46 ` Joe Buck @ 2007-11-15 21:53 ` Richard Kenner 2007-11-15 22:04 ` Ian Lance Taylor 2007-11-15 22:47 ` Diego Novillo 1 sibling, 2 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-15 21:53 UTC (permalink / raw) To: dnovillo; +Cc: Joe.Buck, fleury, gcc > I don't believe this is a strong argument. My contention is, and has > always been, that GCC is _already_ trivial to integrate into a > proprietary compiler. There is at least one compiler I know that does this. I believe that any such compiler would violate the GPL. But I also believe it's not in the best interest of the FSF to litigate that matter if the linkage between the compiler is anything other than linked in a single executable. Therefore, I think it's important for us to make it as technically hard as possible for people to do such a linkage by readin and writing tree or communicating as different libraries or DLLs. I'm very much against any sort of "plug in" precisely for this reason. > IMO, the benefits we gain in making GCC a more attractive code base, far > outweigh the fears of someone co-opting it for their own proprietary uses. That depends on the importance you attach to the philosophy of free software. I suspect RMS attaches much more importance to that than anybody on this list. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 21:53 ` Richard Kenner @ 2007-11-15 22:04 ` Ian Lance Taylor 2007-11-15 22:46 ` Richard Kenner ` (3 more replies) 2007-11-15 22:47 ` Diego Novillo 1 sibling, 4 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-15 22:04 UTC (permalink / raw) To: Richard Kenner; +Cc: dnovillo, Joe.Buck, fleury, gcc kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > I don't believe this is a strong argument. My contention is, and has > > always been, that GCC is _already_ trivial to integrate into a > > proprietary compiler. There is at least one compiler I know that does this. > > I believe that any such compiler would violate the GPL. But I also believe > it's not in the best interest of the FSF to litigate that matter if the > linkage between the compiler is anything other than linked in a single > executable. Therefore, I think it's important for us to make it as > technically hard as possible for people to do such a linkage by readin and > writing tree or communicating as different libraries or DLLs. I'm very > much against any sort of "plug in" precisely for this reason. We can make it as technically hard as possible, but it's way too late to make it technically hard. In fact, it's easy. You have to write some code to translate from tree to your proprietary IR, and then you have to plug that code into passes.c. If gcc supports plugins, then all we've eliminated is the need to plug that code into passes.c. But that is the easiest part of the job. Adding plugins is not going to require us to support a stable tree interface or anything along those lines; if it did, I would oppose that. So this seems to me to be a very weak argument against plugins. Adding plugins does not make it noticeably easier to integrate gcc's frontend with a proprietary compiler. And adding plugins would not change the issue of whether such a combination violated the GPL. Do you disagree with this assessment? I think it's quite important for gcc's long-term health to permit and even encourage academic researchers and students to use it. And I see plugins as directly supporting that goal. Note that I don't see any problem with requiring (or attempting to require) that any plugin be covered by the GPL. So from my perspective the downside of plugins is very small, and the upside is very large. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:04 ` Ian Lance Taylor @ 2007-11-15 22:46 ` Richard Kenner 2007-11-15 22:49 ` Diego Novillo ` (2 more replies) 2007-11-15 22:53 ` Andrew Haley ` (2 subsequent siblings) 3 siblings, 3 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-15 22:46 UTC (permalink / raw) To: iant; +Cc: Joe.Buck, dnovillo, fleury, gcc > In fact, it's easy. You have to write some code to translate from > tree to your proprietary IR, and then you have to plug that code > into passes.c. Well first of all, that code becomes GPL so the IR isn't truely "proprietary". > So this seems to me to be a very weak argument against plugins. > Adding plugins does not make it noticeably easier to integrate gcc's > frontend with a proprietary compiler. And adding plugins would not > change the issue of whether such a combination violated the GPL. > > Do you disagree with this assessment? No, not in that case, but I don't see that as the only case. Another case would be somebody who wanted to keep an optimizer proprietary by making it a plug-in. My view is that because of the linkage with the GCC IR, it can't be proprietary in that case, but that's the harder argument to make legally. > I think it's quite important for gcc's long-term health to permit and > even encourage academic researchers and students to use it. And I see > plugins as directly supporting that goal. I don't see that. Why is it that much harder to link in with GCC than doing it as a plugin? ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:46 ` Richard Kenner @ 2007-11-15 22:49 ` Diego Novillo 2007-11-15 23:24 ` Richard Kenner 2007-11-16 15:49 ` Alexander Lamaison 2007-11-15 22:54 ` Benjamin Smedberg 2007-11-15 23:50 ` Ian Lance Taylor 2 siblings, 2 replies; 108+ messages in thread From: Diego Novillo @ 2007-11-15 22:49 UTC (permalink / raw) To: Richard Kenner; +Cc: iant, Joe.Buck, fleury, gcc Richard Kenner wrote: > No, not in that case, but I don't see that as the only case. Another > case would be somebody who wanted to keep an optimizer proprietary by > making it a plug-in. My view is that because of the linkage with the > GCC IR, it can't be proprietary in that case, but that's the harder argument > to make legally. I don't think we can argue legalities here. All we can do is say that if they are using plug-ins, they are forced to include GPL'd header files and link against GPL'd code. The rest is up to the FSF legal folks. > I don't see that. Why is it that much harder to link in with GCC than doing > it as a plugin? Limited time and steep learning curves. Typically, researchers are interested in rapid-prototyping to keep the paper mill going. Plug-ins offers a simple method for avoiding the latencies of repeated bootstrap cycles. Several projects will survive the initial prototyping stages and become techniques we can apply in industrial settings. We want to attract that. Plus we want to attract the grad students that did the research and graduate with a favourable attitude towards using GCC in their future career. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:49 ` Diego Novillo @ 2007-11-15 23:24 ` Richard Kenner 2007-11-15 23:37 ` Diego Novillo 2007-11-16 1:39 ` Ian Lance Taylor 2007-11-16 15:49 ` Alexander Lamaison 1 sibling, 2 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-15 23:24 UTC (permalink / raw) To: dnovillo; +Cc: Joe.Buck, fleury, gcc, iant > Limited time and steep learning curves. Typically, researchers are > interested in rapid-prototyping to keep the paper mill going. Plug-ins > offers a simple method for avoiding the latencies of repeated bootstrap > cycles. I don't follow. If you're developing an optimizer, you need to do the bootstrap to test the optimizer no matter how it connects to the rest of the compiler. All you save is that you do a smaller link, but that time is measured in seconds on modern machines. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 23:24 ` Richard Kenner @ 2007-11-15 23:37 ` Diego Novillo 2007-11-16 0:24 ` Richard Kenner 2007-11-16 1:39 ` Ian Lance Taylor 1 sibling, 1 reply; 108+ messages in thread From: Diego Novillo @ 2007-11-15 23:37 UTC (permalink / raw) To: Richard Kenner; +Cc: Joe.Buck, fleury, gcc, iant Richard Kenner wrote: > I don't follow. If you're developing an optimizer, you need to do the > bootstrap to test the optimizer no matter how it connects to the rest > of the compiler. All you save is that you do a smaller link, but that > time is measured in seconds on modern machines. No, you don't. All you need is an existing GCC binary installed somewhere in your path that accepts -fplugin=mypass.so. All you compile is your pass, you don't need to even build GCC. Plug-ins also facilitate other kinds of work that are not related to optimization passes. Static analysis, refactoring tools, visualization, code navigation, etc. Sean described a variety of different applications they had implemented with their plug-in framework at the last summit. It was all pretty impressive. I agree with your point of not getting into legal discussions here, so I won't comment on your previous posting. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 23:37 ` Diego Novillo @ 2007-11-16 0:24 ` Richard Kenner 2007-11-16 1:24 ` Diego Novillo 0 siblings, 1 reply; 108+ messages in thread From: Richard Kenner @ 2007-11-16 0:24 UTC (permalink / raw) To: dnovillo; +Cc: Joe.Buck, fleury, gcc, iant > > I don't follow. If you're developing an optimizer, you need to do the > > bootstrap to test the optimizer no matter how it connects to the rest > > of the compiler. All you save is that you do a smaller link, but that > > time is measured in seconds on modern machines. > > No, you don't. All you need is an existing GCC binary installed > somewhere in your path that accepts -fplugin=mypass.so. All you compile > is your pass, you don't need to even build GCC. No, I mean for *testing* you need to do a bootstrap. I'm not talking about the minimum actually needed to build. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 0:24 ` Richard Kenner @ 2007-11-16 1:24 ` Diego Novillo 2007-11-24 23:31 ` Alexandre Oliva 0 siblings, 1 reply; 108+ messages in thread From: Diego Novillo @ 2007-11-16 1:24 UTC (permalink / raw) To: Richard Kenner; +Cc: Joe.Buck, fleury, gcc, iant Richard Kenner wrote: > No, I mean for *testing* you need to do a bootstrap. I'm not talking > about the minimum actually needed to build. Nope, you don't. If you are doing static analysis, for instance, you don't care nor need to bootstrap GCC. You just need to load your module every time a file is compiled. If you are doing a pass that you are testing and/or prototyping, you don't want to waste time rebuilding the whole compiler. If/when your pass reaches certain maturity, you think it's ready for production, and people think it's a good idea to have it in the compiler, then you convert it into a static pass and you go through the traditional bootstrap process. Similarly, for visualization plug-ins, you don't want/need to bootstrap the compiler. That's the core idea with plug-ins, they allow more flexibility for experimentation. They are not a means for implementing permanent features in the compiler. We would not guarantee ABI nor API stability, there is just no point to doing that. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 1:24 ` Diego Novillo @ 2007-11-24 23:31 ` Alexandre Oliva 2007-11-24 23:33 ` Diego Novillo 0 siblings, 1 reply; 108+ messages in thread From: Alexandre Oliva @ 2007-11-24 23:31 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Kenner, Joe.Buck, fleury, gcc, iant On Nov 15, 2007, Diego Novillo <dnovillo@google.com> wrote: > If/when your pass reaches certain maturity, you think it's ready for > production, and people think it's a good idea to have it in the > compiler, then you convert it into a static pass and you go through > the traditional bootstrap process. > That's the core idea with plug-ins, they allow more flexibility for > experimentation. They are not a means for implementing permanent > features in the compiler. I find the two paragraphs above contradictory. If they're not means for implementing permanent features, then converting a pass implemented as a plugin that's ready for production into a static pass is what? It raises an issue of how important it is that this plugin architecture, if it is to exist, be similar to the internals of GCC, such that the conversion is as simple as possible. OTOH, the more GCC internals it relies on, the less useful it is to abstract away GCC's internal complexities. Looks like conflicting goals to me :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-24 23:31 ` Alexandre Oliva @ 2007-11-24 23:33 ` Diego Novillo 2007-11-25 0:11 ` Alexandre Oliva 0 siblings, 1 reply; 108+ messages in thread From: Diego Novillo @ 2007-11-24 23:33 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Richard Kenner, Joe.Buck, fleury, gcc, iant Alexandre Oliva wrote: > On Nov 15, 2007, Diego Novillo <dnovillo@google.com> wrote: > >> If/when your pass reaches certain maturity, you think it's ready for >> production, and people think it's a good idea to have it in the >> compiler, then you convert it into a static pass and you go through >> the traditional bootstrap process. > >> That's the core idea with plug-ins, they allow more flexibility for >> experimentation. They are not a means for implementing permanent >> features in the compiler. > > I find the two paragraphs above contradictory. If they're not means > for implementing permanent features, then converting a pass > implemented as a plugin that's ready for production into a static pass > is what? Converting a pass implemented as a plug-in into a static pass is the way to add permanent feature in the compiler. In principle, I don't think we'll want to implement permanent features as plug-ins. > It raises an issue of how important it is that this plugin > architecture, if it is to exist, be similar to the internals of GCC, > such that the conversion is as simple as possible. There is no conversion. Read Sean Callanan's paper in this year's GCC Summit proceedings. Plug-in code uses the same internal code as statically linked passes. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-24 23:33 ` Diego Novillo @ 2007-11-25 0:11 ` Alexandre Oliva 0 siblings, 0 replies; 108+ messages in thread From: Alexandre Oliva @ 2007-11-25 0:11 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Kenner, Joe.Buck, fleury, gcc, iant On Nov 24, 2007, Diego Novillo <dnovillo@google.com> wrote: > Alexandre Oliva wrote: >> On Nov 15, 2007, Diego Novillo <dnovillo@google.com> wrote: >> >>> If/when your pass reaches certain maturity, you think it's ready for >>> production, and people think it's a good idea to have it in the >>> compiler, then you convert it into a static pass and you go through >>> the traditional bootstrap process. >> >>> That's the core idea with plug-ins, they allow more flexibility for >>> experimentation. They are not a means for implementing permanent >>> features in the compiler. >> >> I find the two paragraphs above contradictory. If they're not means >> for implementing permanent features, then converting a pass >> implemented as a plugin that's ready for production into a static pass >> is what? > Converting a pass implemented as a plug-in into a static pass is the > way to add permanent feature in the compiler. In principle, I don't > think we'll want to implement permanent features as plug-ins. Agreed. >> It raises an issue of how important it is that this plugin >> architecture, if it is to exist, be similar to the internals of GCC, >> such that the conversion is as simple as possible. > There is no conversion. Then I guess I don't see any value whatsoever in this particular plugin architecture in overcoming the difficulties unexperienced GCC developers face :-( > Plug-in code uses the same internal code as statically linked > passes. Then they can be means for implementing permanent features in the compiler, after all. I guess we can agree on that ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 23:24 ` Richard Kenner 2007-11-15 23:37 ` Diego Novillo @ 2007-11-16 1:39 ` Ian Lance Taylor 1 sibling, 0 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-16 1:39 UTC (permalink / raw) To: Richard Kenner; +Cc: dnovillo, Joe.Buck, fleury, gcc kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > Limited time and steep learning curves. Typically, researchers are > > interested in rapid-prototyping to keep the paper mill going. Plug-ins > > offers a simple method for avoiding the latencies of repeated bootstrap > > cycles. > > I don't follow. If you're developing an optimizer, you need to do the > bootstrap to test the optimizer no matter how it connects to the rest > of the compiler. All you save is that you do a smaller link, but that > time is measured in seconds on modern machines. But users who are not gcc developers have trouble doing a bootstrap. Our build process is complicated, and it is not getting simpler. And the sorts of researchers that dnovillo is talking about don't need to do a bootstrap routinely. They are experimenting with new optimizations or with static analysis. They aren't generating actual code. A bootstrap is beside the point. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-15 22:49 ` Diego Novillo 2007-11-15 23:24 ` Richard Kenner @ 2007-11-16 15:49 ` Alexander Lamaison 2007-11-16 16:08 ` Martin Jambor 1 sibling, 1 reply; 108+ messages in thread From: Alexander Lamaison @ 2007-11-16 15:49 UTC (permalink / raw) To: 'Diego Novillo', 'Richard Kenner' Cc: iant, Joe.Buck, fleury, gcc Diego Novillo wrote: > Richard Kenner wrote: > > > I don't see that. Why is it that much harder to link in with GCC > than doing > > it as a plugin? > > Limited time and steep learning curves. Typically, researchers are > interested in rapid-prototyping to keep the paper mill going. Plug-ins > offers a simple method for avoiding the latencies of repeated bootstrap > cycles. > > Several projects will survive the initial prototyping stages and become > techniques we can apply in industrial settings. We want to attract > that. Plus we want to attract the grad students that did the research > and graduate with a favourable attitude towards using GCC in their > future career. As a research student who spent 6 months working on an improvement to GCC, I agree with all of Diego's remarks. Out of the 6 months, 4 were spent learning the GCC internals and fighting the GCC build process, 1 was spent writing up leaving 1 month of actual productive research. While not all of this would be solved by a plugin system (a lot was down to documentation) it would have significantly increased the amount of time I had to make useful contributions. I fully understand that this can seems strange to people who know GCC like the back of their hand, but to a newcomer it is a huge task just to write a single useful line of code. I'm sure many give up before ever reaching that point. Alex Lamaison Imperial College London ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 15:49 ` Alexander Lamaison @ 2007-11-16 16:08 ` Martin Jambor 2007-11-16 16:12 ` Alexander Lamaison 0 siblings, 1 reply; 108+ messages in thread From: Martin Jambor @ 2007-11-16 16:08 UTC (permalink / raw) To: Alexander Lamaison Cc: Diego Novillo, Richard Kenner, iant, Joe.Buck, fleury, gcc Hi, On Nov 16, 2007 12:16 PM, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote: > Diego Novillo wrote: > > Several projects will survive the initial prototyping stages and become > > techniques we can apply in industrial settings. We want to attract > > that. Plus we want to attract the grad students that did the research > > and graduate with a favourable attitude towards using GCC in their > > future career. > > As a research student who spent 6 months working on an improvement to GCC, I > agree with all of Diego's remarks. Out of the 6 months, 4 were spent > learning the GCC internals and fighting the GCC build process, 1 was spent > writing up leaving 1 month of actual productive research. While not all of > this would be solved by a plugin system (a lot was down to documentation) it > would have significantly increased the amount of time I had to make useful > contributions. I have started looking into GCC slightly more than a year ago, since then I have successfully finished thesis on interprocedural optimizations which was largely a research project. I am still essentially a newcomer, yet I completely disagree. When I think what a plugin framework would help me with, I cannot think of anything significant. It would have saved me modifying passes.c which was not really an issue. Everything else would be as complicated as it was or even more. So as far as attracting new programmers, researchers and inexperienced students in particular is concerned, I think that effort that implementing plugins would take would be much better spent on keeping documentation up to date, possibly improving it (hey, Alexander, what were your problems, someone might answer them on Wiki for others!) and, in particular, staying as friendly and forgiving community as you are (especially on IRC anyway :-). IMHO 4 months of learning how to work with GCC internals seems to be completely reasonable time for me. Compilers are complex and GCC is no toy. (And plugins won't help with this, will they?) Of course, I understand there might be other and perhaps more important uses of plugins. Martin ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:08 ` Martin Jambor @ 2007-11-16 16:12 ` Alexander Lamaison 0 siblings, 0 replies; 108+ messages in thread From: Alexander Lamaison @ 2007-11-16 16:12 UTC (permalink / raw) To: Martin Jambor; +Cc: Diego Novillo, Richard Kenner, iant, Joe.Buck, fleury, gcc Quoting Martin Jambor <jamborm@matfyz.cz>: > So as far as attracting new programmers, researchers and inexperienced > students in particular is concerned, I think that effort that > implementing plugins would take would be much better spent on keeping > documentation up to date, possibly improving it (hey, Alexander, what > were your problems, someone might answer them on Wiki for others!) > and, in particular, staying as friendly and forgiving community as you > are (especially on IRC anyway :-). I certainly agree with this! The same effort spent on documentation rather than on a plugin system would, imho, give greater value. But, as there seems to be a willingness to work on plugins in contrast to the willingness to document, I am supporting progress wherever it is on offer. The project is over and eventually I solved the problems through sweat and tears. I have the solutions scribbled down somewhere and eventually I mean to put the up on the web somewhere to save others the same pain. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:46 ` Richard Kenner 2007-11-15 22:49 ` Diego Novillo @ 2007-11-15 22:54 ` Benjamin Smedberg 2007-11-15 23:50 ` Ian Lance Taylor 2 siblings, 0 replies; 108+ messages in thread From: Benjamin Smedberg @ 2007-11-15 22:54 UTC (permalink / raw) To: Richard Kenner; +Cc: iant, Joe.Buck, dnovillo, fleury, gcc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Kenner wrote: >> I think it's quite important for gcc's long-term health to permit and >> even encourage academic researchers and students to use it. And I see >> plugins as directly supporting that goal. > > I don't see that. Why is it that much harder to link in with GCC than doing > it as a plugin? To provide an example: Mozilla has been using elsa/oink to do static analysis and rewriting of the codebase. We would love to use a more mature and correct frontend such as GCC... and we would like to eventually have this static analysis be a standard part of the build process when using the GCC compiler. To avoid requiring everyone who does Mozilla hacking to also do a custom-built GCC would be to write just the static analysis as a plugin, compile that to a .so, and then build with an extra flag such as g++ - -static-analyze=/custom/libmozstaticanalysis.so... in many cases we could even pre-compile this file for common versions of GCC. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation benjamin@smedbergs.us http://benjamin.smedbergs.us/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPMKISSwGp5sTYNkRAtX2AKDa2OWDLgQkeXLQjzcI5BzqGf3b2ACgmm1r jnbvtmAnq0GPPb19M/92lFo= =af7b -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:46 ` Richard Kenner 2007-11-15 22:49 ` Diego Novillo 2007-11-15 22:54 ` Benjamin Smedberg @ 2007-11-15 23:50 ` Ian Lance Taylor 2 siblings, 0 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-15 23:50 UTC (permalink / raw) To: Richard Kenner; +Cc: Joe.Buck, dnovillo, fleury, gcc kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > In fact, it's easy. You have to write some code to translate from > > tree to your proprietary IR, and then you have to plug that code > > into passes.c. > > Well first of all, that code becomes GPL so the IR isn't truely "proprietary". I'm with you on that. The fact remains, people have done this already. Whether the result is legally proprietary or not is almost irrelevant; as you said earlier, the FSF is unlikely to actually sue. > > So this seems to me to be a very weak argument against plugins. > > Adding plugins does not make it noticeably easier to integrate gcc's > > frontend with a proprietary compiler. And adding plugins would not > > change the issue of whether such a combination violated the GPL. > > > > Do you disagree with this assessment? > > No, not in that case, but I don't see that as the only case. Another > case would be somebody who wanted to keep an optimizer proprietary by > making it a plug-in. My view is that because of the linkage with the > GCC IR, it can't be proprietary in that case, but that's the harder argument > to make legally. I can not deny the possibility of somebody writing an (effectively) proprietary optimization pass. However, I consider that to be both unlikely and irrelevant. People can always make private changes to gcc. We care about proprietary changes if they start distributing them. But that is an unlikely scenario. There is no money to be made in compiler optimization. If we make it clear that we consider any plugin to be covered by the GPL, then any attempt to sell a proprietary optimization will face community opposition, thus making even less business sense. And in the end, what will they have? A marginal improvement over the standard compiler. Since they can not hide the results, we can figure out what they are doing and recreate it. In fact, it will be easier for us to do so than it would be for a private port. So I think this is a groundless fear. When considering hypothetical consequences, we need to consider both their likelihood and their benefit or cost. This one is both unlikely and has low cost. > > I think it's quite important for gcc's long-term health to permit and > > even encourage academic researchers and students to use it. And I see > > plugins as directly supporting that goal. > > I don't see that. Why is it that much harder to link in with GCC than doing > it as a plugin? It is harder for people who are not used to the myriad details of building gcc themselves. Most people these days do not build gcc themselves, and on gcc-help you will see the plaintive cries of those who do. We're talking about grad students focused on their research here, not people who want to learn the arcana of our build system. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:04 ` Ian Lance Taylor 2007-11-15 22:46 ` Richard Kenner @ 2007-11-15 22:53 ` Andrew Haley 2007-11-15 22:55 ` Ian Lance Taylor 2007-11-16 0:01 ` Emmanuel Fleury 2007-11-16 17:27 ` Bernd Schmidt 3 siblings, 1 reply; 108+ messages in thread From: Andrew Haley @ 2007-11-15 22:53 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Ian Lance Taylor writes: > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > > > I don't believe this is a strong argument. My contention is, > > > and has always been, that GCC is _already_ trivial to integrate > > > into a proprietary compiler. There is at least one compiler I > > > know that does this. > > > > I believe that any such compiler would violate the GPL. But I > > also believe it's not in the best interest of the FSF to litigate > > that matter if the linkage between the compiler is anything other > > than linked in a single executable. Therefore, I think it's > > important for us to make it as technically hard as possible for > > people to do such a linkage by readin and writing tree or > > communicating as different libraries or DLLs. I'm very much > > against any sort of "plug in" precisely for this reason. > > We can make it as technically hard as possible, but it's way too late > to make it technically hard. In fact, it's easy. You have to write > some code to translate from tree to your proprietary IR, and then you > have to plug that code into passes.c. Sure, but you then have to maintain your port forever, and there is a substantial cost to this. I am pretty sure that if there were a stable API to get trees out of GCC, people would have bolted gcc into proprietary compilers. As there isn't a stable way to do it, it's easier not to do it that way, and instead to contribute to gcc. > If gcc supports plugins, then all we've eliminated is the need to > plug that code into passes.c. But that is the easiest part of the > job. Adding plugins is not going to require us to support a stable > tree interface or anything along those lines; if it did, I would > oppose that. Ahhhhhh. I don't know about that: once we have a plugin infrastructure, we have to document it and there will be pressure to stabilize it. I don't believe that an unstable plugin architecture has any viability at all. > So this seems to me to be a very weak argument against plugins. > Adding plugins does not make it noticeably easier to integrate gcc's > frontend with a proprietary compiler. And adding plugins would not > change the issue of whether such a combination violated the GPL. > > Do you disagree with this assessment? I think there is a real possibility that, had we had such a plugin interface years ago, some of the gcc back-ends and optimization work we have would never have been paid for by some companies, and so gcc would be a worse compiler. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:53 ` Andrew Haley @ 2007-11-15 22:55 ` Ian Lance Taylor 2007-11-16 13:33 ` Andrew Haley 0 siblings, 1 reply; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-15 22:55 UTC (permalink / raw) To: Andrew Haley; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Andrew Haley <aph@redhat.com> writes: > > We can make it as technically hard as possible, but it's way too late > > to make it technically hard. In fact, it's easy. You have to write > > some code to translate from tree to your proprietary IR, and then you > > have to plug that code into passes.c. > > Sure, but you then have to maintain your port forever, and there is a > substantial cost to this. I am pretty sure that if there were a > stable API to get trees out of GCC, people would have bolted gcc into > proprietary compilers. As there isn't a stable way to do it, it's > easier not to do it that way, and instead to contribute to gcc. I agree that there is a cost to maintaining your port. I disagree that plugins make it any cheaper. See below. > > If gcc supports plugins, then all we've eliminated is the need to > > plug that code into passes.c. But that is the easiest part of the > > job. Adding plugins is not going to require us to support a stable > > tree interface or anything along those lines; if it did, I would > > oppose that. > > Ahhhhhh. I don't know about that: once we have a plugin > infrastructure, we have to document it and there will be pressure to > stabilize it. I don't believe that an unstable plugin architecture > has any viability at all. I disagree. In fact, if creating a plugin architecture comes with a requirement to make a stable structure for trees, then I'm opposed to it. That would hurt us far more than it would help. This is not a slippery slope. An unstable plugin architecture is still very useful for our users. Correct installation of a patched gcc is an awkward affair that many people get wrong. Correct installation of a plugin requires no more than a command line option. Plugins make it easy for people to share their gcc extensions across projects or across university departments. > > So this seems to me to be a very weak argument against plugins. > > Adding plugins does not make it noticeably easier to integrate gcc's > > frontend with a proprietary compiler. And adding plugins would not > > change the issue of whether such a combination violated the GPL. > > > > Do you disagree with this assessment? > > I think there is a real possibility that, had we had such a plugin > interface years ago, some of the gcc back-ends and optimization work > we have would never have been paid for by some companies, and so gcc > would be a worse compiler. Most new gcc back-ends are private, so I don't buy that part of the argument. And in any case nobody is talking about plug-ins for gcc backends. We're talking about plugins at the tree/GIMPLE level. And, frankly, very few people are paying for general new gcc optimizations. As far as I know, the only people doing so are companies like IBM and Red Hat, and they would contribute their changes anyhow. Do you have any examples in mind? When I was in the business of convincing people to pay for gcc work, I had a laundry list of general gcc improvements to sell. I was never able to get a dime except for target specific improvements. A plugin architecture would not make any difference to that kind of work. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:55 ` Ian Lance Taylor @ 2007-11-16 13:33 ` Andrew Haley 2007-11-16 16:18 ` Ian Lance Taylor 0 siblings, 1 reply; 108+ messages in thread From: Andrew Haley @ 2007-11-16 13:33 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Ian Lance Taylor writes: > Andrew Haley <aph@redhat.com> writes: > > > > If gcc supports plugins, then all we've eliminated is the need to > > > plug that code into passes.c. But that is the easiest part of the > > > job. Adding plugins is not going to require us to support a stable > > > tree interface or anything along those lines; if it did, I would > > > oppose that. > > > > Ahhhhhh. I don't know about that: once we have a plugin > > infrastructure, we have to document it and there will be pressure to > > stabilize it. I don't believe that an unstable plugin architecture > > has any viability at all. > > I disagree. In fact, if creating a plugin architecture comes with a > requirement to make a stable structure for trees, then I'm opposed to > it. That would hurt us far more than it would help. This is not a > slippery slope. > > An unstable plugin architecture is still very useful for our users. > Correct installation of a patched gcc is an awkward affair that many > people get wrong. Correct installation of a plugin requires no more > than a command line option. Plugins make it easy for people to share > their gcc extensions across projects or across university departments. Even if the interafce changes continuously? Maybe. I find it hard to believe, but we'll just have to agree to differ. > > > So this seems to me to be a very weak argument against plugins. > > > Adding plugins does not make it noticeably easier to integrate gcc's > > > frontend with a proprietary compiler. And adding plugins would not > > > change the issue of whether such a combination violated the GPL. > > > > > > Do you disagree with this assessment? > > > > I think there is a real possibility that, had we had such a plugin > > interface years ago, some of the gcc back-ends and optimization work > > we have would never have been paid for by some companies, and so gcc > > would be a worse compiler. > > Most new gcc back-ends are private, so I don't buy that part of the > argument. And in any case nobody is talking about plug-ins for gcc > backends. We're talking about plugins at the tree/GIMPLE level. Yeah, I know. I'm thinking about proprietary compilers (not just back-ends, optimization passes) bolted on to a gcc front-end to get Linux compatibility. > And, frankly, very few people are paying for general new gcc > optimizations. As far as I know, the only people doing so are > companies like IBM and Red Hat, and they would contribute their > changes anyhow. Do you have any examples in mind? ISTR that at least part of if-conversion was paid for, but I can't remember how much of what I know is confidential and how much is just plain wrong. > When I was in the business of convincing people to pay for gcc > work, I had a laundry list of general gcc improvements to sell. I > was never able to get a dime except for target specific > improvements. A plugin architecture would not make any difference > to that kind of work. No, but it might mean that entire gcc ports go away, as people who already have in-house compilers use them with a gcc front-end for Linux ports, rather than funding gcc ports. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 13:33 ` Andrew Haley @ 2007-11-16 16:18 ` Ian Lance Taylor 2007-11-16 16:21 ` Andrew Haley ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-16 16:18 UTC (permalink / raw) To: Andrew Haley; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Andrew Haley <aph@redhat.com> writes: > > Most new gcc back-ends are private, so I don't buy that part of the > > argument. And in any case nobody is talking about plug-ins for gcc > > backends. We're talking about plugins at the tree/GIMPLE level. > > Yeah, I know. I'm thinking about proprietary compilers (not just > back-ends, optimization passes) bolted on to a gcc front-end to get > Linux compatibility. As we've discussed previously, we are already seeing that without plugins: GCCfss. Sun took gcc's frontend and attached it to their proprietary backend. So in my view introducing plugins will not make a substantive difference here. > > When I was in the business of convincing people to pay for gcc > > work, I had a laundry list of general gcc improvements to sell. I > > was never able to get a dime except for target specific > > improvements. A plugin architecture would not make any difference > > to that kind of work. > > No, but it might mean that entire gcc ports go away, as people who > already have in-house compilers use them with a gcc front-end for > Linux ports, rather than funding gcc ports. But as you know, most gcc ports are never contributed anyhow. Ports that people hire Red Hat to do are contributed, but I can easily count six gcc ports I've seen myself that were never contributed. So again I don't see a substantive difference here. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:18 ` Ian Lance Taylor @ 2007-11-16 16:21 ` Andrew Haley 2007-11-16 16:53 ` Basile STARYNKEVITCH 2007-11-16 16:56 ` Ian Lance Taylor 2007-11-16 16:24 ` Basile STARYNKEVITCH 2007-11-16 19:09 ` Martin Michlmayr 2 siblings, 2 replies; 108+ messages in thread From: Andrew Haley @ 2007-11-16 16:21 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Ian Lance Taylor writes: > Andrew Haley <aph@redhat.com> writes: > > > > Most new gcc back-ends are private, so I don't buy that part of the > > > argument. And in any case nobody is talking about plug-ins for gcc > > > backends. We're talking about plugins at the tree/GIMPLE level. > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > back-ends, optimization passes) bolted on to a gcc front-end to get > > Linux compatibility. > > As we've discussed previously, we are already seeing that without > plugins: GCCfss. Sun took gcc's frontend and attached it to their > proprietary backend. So in my view introducing plugins will not make > a substantive difference here. Well, yeah, but no-one ever said it wouldn't be possible without plugins. > > > When I was in the business of convincing people to pay for gcc > > > work, I had a laundry list of general gcc improvements to sell. I > > > was never able to get a dime except for target specific > > > improvements. A plugin architecture would not make any difference > > > to that kind of work. > > > > No, but it might mean that entire gcc ports go away, as people who > > already have in-house compilers use them with a gcc front-end for > > Linux ports, rather than funding gcc ports. > > But as you know, most gcc ports are never contributed anyhow. Sure, but they are still free software: if the compiler gets distributed, so does its source code. Of couse, assigning copyright to FSF is nice, but freedom is much more important. > Ports that people hire Red Hat to do are contributed, but I can > easily count six gcc ports I've seen myself that were never > contributed. > So again I don't see a substantive difference here. I guess it depends on what you mean by "substantive". As I said, I suspect that if it were easier to decouple the gcc front-end from the back-end and to maintain the resulting compiler, there would be fewer free compilers. And no, neither of us can prove it without doing the experiment. I insist, however, that when it comes to a change that potentially reduces freedom, the burden of proof -- or at least of evidence -- is on those wanting to make the change. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:21 ` Andrew Haley @ 2007-11-16 16:53 ` Basile STARYNKEVITCH 2007-11-16 16:56 ` Ian Lance Taylor 1 sibling, 0 replies; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-16 16:53 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc Andrew Haley wrote: > > > > But as you know, most gcc ports are never contributed anyhow. > > Sure, but they are still free software: if the compiler gets > distributed, so does its source code. Of couse, assigning copyright > to FSF is nice, but freedom is much more important. Oh I fully understand that now. So most GCC ports are GPL-ed but outside FSF source tree. Hence, a plugin machinery (including for backends) would make this easier! I also expressed (orally) the concern (at previous GCC summit, Ottawa july 2007) that getting the copyright assignment signed is a lot of work in some organizations and I would hope that the FSF might consider making it easier (I don't know exactly how, as a non lawyer I would dream of simple GPLed contributions, with the copyright owner giving the FSF the right to sue on its behalf, ...) but apparently it is not a concern. I still believe that GCC needs more developers, and attracting them could be a concern. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:21 ` Andrew Haley 2007-11-16 16:53 ` Basile STARYNKEVITCH @ 2007-11-16 16:56 ` Ian Lance Taylor 2007-11-16 16:58 ` Diego Novillo ` (2 more replies) 1 sibling, 3 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-16 16:56 UTC (permalink / raw) To: Andrew Haley; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Andrew Haley <aph@redhat.com> writes: > Ian Lance Taylor writes: > > Andrew Haley <aph@redhat.com> writes: > > > > > > Most new gcc back-ends are private, so I don't buy that part of the > > > > argument. And in any case nobody is talking about plug-ins for gcc > > > > backends. We're talking about plugins at the tree/GIMPLE level. > > > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > > back-ends, optimization passes) bolted on to a gcc front-end to get > > > Linux compatibility. > > > > As we've discussed previously, we are already seeing that without > > plugins: GCCfss. Sun took gcc's frontend and attached it to their > > proprietary backend. So in my view introducing plugins will not make > > a substantive difference here. > > Well, yeah, but no-one ever said it wouldn't be possible without > plugins. I'm sorry, I've lost the sense of the argument here. I thought you were arguing that plugins would make this more likely. I'm saying that it's already happening, and that it's not noticeably easier with plugins. So can you repeat your point? > > > > When I was in the business of convincing people to pay for gcc > > > > work, I had a laundry list of general gcc improvements to sell. I > > > > was never able to get a dime except for target specific > > > > improvements. A plugin architecture would not make any difference > > > > to that kind of work. > > > > > > No, but it might mean that entire gcc ports go away, as people who > > > already have in-house compilers use them with a gcc front-end for > > > Linux ports, rather than funding gcc ports. > > > > But as you know, most gcc ports are never contributed anyhow. > > Sure, but they are still free software: if the compiler gets > distributed, so does its source code. Of couse, assigning copyright > to FSF is nice, but freedom is much more important. If I follow this, it seems that you are saying that if we have plugins, some people will choose to use them to get a gcc frontend for a proprietary compiler rather than doing a gcc port. I'm sorry, I don't buy this at all. Again, people can already do this, and adding plugins does not make it substantially easier. > > Ports that people hire Red Hat to do are contributed, but I can > > easily count six gcc ports I've seen myself that were never > > contributed. > > > So again I don't see a substantive difference here. > > I guess it depends on what you mean by "substantive". As I said, I > suspect that if it were easier to decouple the gcc front-end from the > back-end and to maintain the resulting compiler, there would be fewer > free compilers. And no, neither of us can prove it without doing the > experiment. I insist, however, that when it comes to a change that > potentially reduces freedom, the burden of proof -- or at least of > evidence -- is on those wanting to make the change. I'm very sorry to hear you take that position. I think you are letting an unlikely fear sacrifice a clear benefit. I have a different fear: that gcc will become increasing irrelevant, as more and more new programmers learn to work on alternative free compilers instead. That is neutral with regard to freedom, but it will tend to lose the many years of experience which have been put into gcc. In my view, if we can't even get ourselves together to permit something as simple as plugins with an unstable API, then we deserve to lose. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:56 ` Ian Lance Taylor @ 2007-11-16 16:58 ` Diego Novillo 2007-11-16 17:08 ` Andrew Haley 2007-11-16 17:18 ` Richard Kenner 2 siblings, 0 replies; 108+ messages in thread From: Diego Novillo @ 2007-11-16 16:58 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Andrew Haley, Richard Kenner, Joe.Buck, fleury, gcc Ian Lance Taylor wrote: > I have a different fear: that gcc will become increasing irrelevant, > as more and more new programmers learn to work on alternative free > compilers instead. That is neutral with regard to freedom, but it > will tend to lose the many years of experience which have been put > into gcc. In my view, if we can't even get ourselves together to > permit something as simple as plugins with an unstable API, then we > deserve to lose. That's precisely my concern. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:56 ` Ian Lance Taylor 2007-11-16 16:58 ` Diego Novillo @ 2007-11-16 17:08 ` Andrew Haley 2007-11-16 17:10 ` Diego Novillo ` (2 more replies) 2007-11-16 17:18 ` Richard Kenner 2 siblings, 3 replies; 108+ messages in thread From: Andrew Haley @ 2007-11-16 17:08 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Ian Lance Taylor writes: > Andrew Haley <aph@redhat.com> writes: > > > Ian Lance Taylor writes: > > > Andrew Haley <aph@redhat.com> writes: > > > > > > > > Most new gcc back-ends are private, so I don't buy that part of the > > > > > argument. And in any case nobody is talking about plug-ins for gcc > > > > > backends. We're talking about plugins at the tree/GIMPLE level. > > > > > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > > > back-ends, optimization passes) bolted on to a gcc front-end to get > > > > Linux compatibility. > > > > > > As we've discussed previously, we are already seeing that without > > > plugins: GCCfss. Sun took gcc's frontend and attached it to their > > > proprietary backend. So in my view introducing plugins will not make > > > a substantive difference here. > > > > Well, yeah, but no-one ever said it wouldn't be possible without > > plugins. > > I'm sorry, I've lost the sense of the argument here. I thought you > were arguing that plugins would make this more likely. I'm saying > that it's already happening, and that it's not noticeably easier > with plugins. So can you repeat your point? Ah, OK. I think that it will be noticeably easier with plugins. If the plugin architecture really doesn't make it easier, my point falls. > > > > > When I was in the business of convincing people to pay for gcc > > > > > work, I had a laundry list of general gcc improvements to sell. I > > > > > was never able to get a dime except for target specific > > > > > improvements. A plugin architecture would not make any difference > > > > > to that kind of work. > > > > > > > > No, but it might mean that entire gcc ports go away, as people who > > > > already have in-house compilers use them with a gcc front-end for > > > > Linux ports, rather than funding gcc ports. > > > > > > But as you know, most gcc ports are never contributed anyhow. > > > > Sure, but they are still free software: if the compiler gets > > distributed, so does its source code. Of couse, assigning copyright > > to FSF is nice, but freedom is much more important. > > If I follow this, it seems that you are saying that if we have > plugins, some people will choose to use them to get a gcc frontend > for a proprietary compiler rather than doing a gcc port. I'm > sorry, I don't buy this at all. Again, people can already do this, > and adding plugins does not make it substantially easier. Well, that's where we differ. I don't at all understand how adding plugins won't make it very much easier. It seems obvious to me that if there is a reasonably well-defined plugin architecture it will be vastly easier to export data from gcc's front-ends to a proprietary compiler. It is entirely beyond my understanding why this isn't also obvious to you. > > > Ports that people hire Red Hat to do are contributed, but I can > > > easily count six gcc ports I've seen myself that were never > > > contributed. > > > > > So again I don't see a substantive difference here. > > > > I guess it depends on what you mean by "substantive". As I said, > > I suspect that if it were easier to decouple the gcc front-end > > from the back-end and to maintain the resulting compiler, there > > would be fewer free compilers. And no, neither of us can prove > > it without doing the experiment. I insist, however, that when it > > comes to a change that potentially reduces freedom, the burden of > > proof -- or at least of evidence -- is on those wanting to make > > the change. > > I'm very sorry to hear you take that position. I think you are > letting an unlikely fear sacrifice a clear benefit. > > I have a different fear: that gcc will become increasing > irrelevant, as more and more new programmers learn to work on > alternative free compilers instead. That is neutral with regard to > freedom, but it will tend to lose the many years of experience > which have been put into gcc. In my view, if we can't even get > ourselves together to permit something as simple as plugins with an > unstable API, then we deserve to lose. OK. Well, that's your view. I don't believe that the presence or absence of plugins will make one iota of differebce to mainstream use of gcc. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:08 ` Andrew Haley @ 2007-11-16 17:10 ` Diego Novillo 2007-11-16 18:17 ` Benjamin Smedberg 2007-11-16 17:15 ` Basile STARYNKEVITCH 2007-11-16 17:16 ` David Edelsohn 2 siblings, 1 reply; 108+ messages in thread From: Diego Novillo @ 2007-11-16 17:10 UTC (permalink / raw) To: Andrew Haley; +Cc: Ian Lance Taylor, Richard Kenner, Joe.Buck, fleury, gcc Andrew Haley wrote: > Well, that's where we differ. I don't at all understand how adding > plugins won't make it very much easier. It seems obvious to me that > if there is a reasonably well-defined plugin architecture it will be > vastly easier to export data from gcc's front-ends to a proprietary > compiler. It is entirely beyond my understanding why this isn't also > obvious to you. Because it is not at all easier. It already is *trivial*. Before plug-ins: put your gimple-to-myIR converter in passes.c After plug-ins: dlopen gimple-to-myIR.so Both represent the same effort. Both require your converter to be kept up-to-date with GCC's ever shifting ABI/API. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:10 ` Diego Novillo @ 2007-11-16 18:17 ` Benjamin Smedberg 2007-11-23 0:25 ` Frank Ch. Eigler 0 siblings, 1 reply; 108+ messages in thread From: Benjamin Smedberg @ 2007-11-16 18:17 UTC (permalink / raw) To: Diego Novillo Cc: Andrew Haley, Ian Lance Taylor, Richard Kenner, Joe.Buck, fleury, gcc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego Novillo wrote: > Before plug-ins: put your gimple-to-myIR converter in passes.c > After plug-ins: dlopen gimple-to-myIR.so > > Both represent the same effort. Both require your converter to be kept > up-to-date with GCC's ever shifting ABI/API. They represent the same effort for somebody writing a plugin pass. They do *not* represent the same effort for a Mozilla hacker who just wants to compile Mozilla with the extra static-checking pass enabled. The fact that they can use a stock GCC (and potentially a precompiled plugin specific to their GCC version) is a huge advantage. Note that we're talking about analysis passes that would never be appropriate for integration with GCC directly: e.g. "statically enforce that the internal typedef PRBool is only ever 0 or 1" or "statically enforce that pointers to subclasses of MMgc::GCObject allocated on the heap are only written through this particular writebarrier pattern"... so arguments about whether we want the code to be integrated into GCC itself are irrelevant. - --BDS - -- Benjamin Smedberg Platform Guru Mozilla Corporation benjamin@smedbergs.us http://benjamin.smedbergs.us/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPdQkSSwGp5sTYNkRAjbiAKCPnFBPN4wXswT35dSx3gpyZv+DWACg3L8X 0ntugTV0nMoJoMTXa1yX+FE= =V32a -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 18:17 ` Benjamin Smedberg @ 2007-11-23 0:25 ` Frank Ch. Eigler 0 siblings, 0 replies; 108+ messages in thread From: Frank Ch. Eigler @ 2007-11-23 0:25 UTC (permalink / raw) To: Benjamin Smedberg Cc: Diego Novillo, Andrew Haley, Ian Lance Taylor, Richard Kenner, Joe.Buck, fleury, gcc Benjamin Smedberg <benjamin@smedbergs.us> writes: > Diego Novillo wrote: >> Before plug-ins: put your gimple-to-myIR converter in passes.c >> After plug-ins: dlopen gimple-to-myIR.so >> >> Both represent the same effort. Both require your converter to be kept >> up-to-date with GCC's ever shifting ABI/API. > > They represent the same effort for somebody writing a plugin pass. They do > *not* represent the same effort for a Mozilla hacker who just wants to > compile Mozilla with the extra static-checking pass enabled. [...] There may be a subtle connection between this and the debugging information correctness thread by Alex Oliva a few weeks ago. It may be that if only gcc's debuginfo for deployed (-O2 -g) code were more complete & more correct, that some such analysis code could work by on-the-fly probing-based instrumentation rather than compiled-in stuff. At least, this applies to the kinds of assertions expressible by something like the old GNU Nana tool. - FChE ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:08 ` Andrew Haley 2007-11-16 17:10 ` Diego Novillo @ 2007-11-16 17:15 ` Basile STARYNKEVITCH 2007-11-24 23:22 ` Alexandre Oliva 2007-11-16 17:16 ` David Edelsohn 2 siblings, 1 reply; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-16 17:15 UTC (permalink / raw) Cc: gcc Andrew Haley wrote: > > Well, that's where we differ. I don't at all understand how adding > plugins won't make it very much easier. It seems obvious to me that > if there is a reasonably well-defined plugin architecture it will be > vastly easier to export data from gcc's front-ends to a proprietary > compiler. It is entirely beyond my understanding why this isn't also > obvious to you. I beg to disagree. Exporting GCC data outside makes practical sense if the data is somehow stable (e.g. from one version of GCC to the next). But a plugin mechanism does not require any stability of any sort. And the current internal representations are not (in my view) stable (and this is good, I am not criticizing GCC here) in the same sense that the accepted languages & GCC options are stable. For example, the "simple" plugin mechanism many people have implicitly in mind is just: something give you the ability to call a dlsymed function inside a dlopened plugin as a pass in a defined (& fixed) position in passes.c. I tend to believe it is not that difficult to implement (it seems to me that the issue is to get it accepted in the trunk). However, this does not guaranty at all that all the internal representation (e.g. the tree.h and other header files) is stable. In other words, such a plugin yourplugin.so (which you coded for future gcc-4.4.3) might be usable from gcc 4.4.3 but not from gcc 4.4.5, and probably not from gcc-4.5 and certainly not from gcc-5.x I'm probably naive, but I think that there are enough incentives (both technical compatibility as above, also legal requirements per GPL, and community & ethical standards of free software at large) that the author of the plugin has interest to publish his source under GPL together with the yourplugin.so file. So a well defined plugin architecture does not mean any stability of internal representations (in their binary detail) or of the many GIMPLE transformations.... Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:15 ` Basile STARYNKEVITCH @ 2007-11-24 23:22 ` Alexandre Oliva 2007-11-25 0:10 ` Chris Lattner 0 siblings, 1 reply; 108+ messages in thread From: Alexandre Oliva @ 2007-11-24 23:22 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: gcc On Nov 16, 2007, Basile STARYNKEVITCH <basile@starynkevitch.net> wrote: > For example, the "simple" plugin mechanism many people have implicitly > in mind is just: something give you the ability to call a dlsymed > function inside a dlopened plugin as a pass in a defined (& fixed) > position in passes.c. I tend to believe it is not that difficult to > implement (it seems to me that the issue is to get it accepted in the > trunk). However, this does not guaranty at all that all the internal > representation (e.g. the tree.h and other header files) is stable. Exactly. And I guess some of this could even be accomplished with LD_PRELOAD. But how useful would that be, really? How far would this go into addressing the real needs that are behind the requests for plugin support? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-24 23:22 ` Alexandre Oliva @ 2007-11-25 0:10 ` Chris Lattner 0 siblings, 0 replies; 108+ messages in thread From: Chris Lattner @ 2007-11-25 0:10 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Basile STARYNKEVITCH, gcc On Nov 24, 2007, at 1:54 PM, Alexandre Oliva wrote: > On Nov 16, 2007, Basile STARYNKEVITCH <basile@starynkevitch.net> > wrote: > >> For example, the "simple" plugin mechanism many people have >> implicitly >> in mind is just: something give you the ability to call a dlsymed >> function inside a dlopened plugin as a pass in a defined (& fixed) >> position in passes.c. I tend to believe it is not that difficult to >> implement (it seems to me that the issue is to get it accepted in the >> trunk). However, this does not guaranty at all that all the internal >> representation (e.g. the tree.h and other header files) is stable. > > Exactly. And I guess some of this could even be accomplished with > LD_PRELOAD. But how useful would that be, really? How far would this > go into addressing the real needs that are behind the requests for > plugin support? Full "plugin support" really encompasses more than having GCC just being able to dlopen a .so file. It means providing (hopefully) well defined extension points for common operations. For example, it should be relatively easy to load a plugin that defines a new tree-ssa pass, and have it get dropped naturally into the pass manager. Alternatively, you could have an extension point for "gimple consumers" that don't care about the optimizer or backend, but just want a way to parse the code and deal with the gimple or generic trees. Examples of this would be static analysis tools or things like the "FFI generator" for scripting languages. To me personally, I'm looking forward to this happening because it means that "llvm-gcc" could conceptually just become a plugin into a standard GCC: the llvm-gcc plugin would use exactly the same extension point as the "static analysis tools" (it doesn't care about the GCC optimizer or backend, so it just wouldn't use it). This would make it potentially easier to deploy the llvm-gcc binary (it's a plugin for a specific gcc, instead of an entire copy of gcc itself), and it would potentially make it easier to keep the tree up to date as GCC moves forward. For the record, I'm fine everything being GPL, the license is not the issue. -Chris ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:08 ` Andrew Haley 2007-11-16 17:10 ` Diego Novillo 2007-11-16 17:15 ` Basile STARYNKEVITCH @ 2007-11-16 17:16 ` David Edelsohn 2007-11-16 17:25 ` Dep, Khushil (GE Money) 2 siblings, 1 reply; 108+ messages in thread From: David Edelsohn @ 2007-11-16 17:16 UTC (permalink / raw) To: Andrew Haley Cc: Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc >>>>> Andrew Haley writes: >> I have a different fear: that gcc will become increasing >> irrelevant, as more and more new programmers learn to work on >> alternative free compilers instead. That is neutral with regard to >> freedom, but it will tend to lose the many years of experience >> which have been put into gcc. In my view, if we can't even get >> ourselves together to permit something as simple as plugins with an >> unstable API, then we deserve to lose. Andrew> OK. Well, that's your view. I don't believe that the presence or Andrew> absence of plugins will make one iota of differebce to mainstream use Andrew> of gcc. The concern is not a first-order effect, but a second-order effect. GCC will improve more and faster if more developers are involved. Plug-ins will encourage more research and development of GCC -- more features and benefits. An improved GCC will attract more users. In my experience, most users prefer GCC because it is free, generates code with "good-enough" performance, supports many architectures and languages, defines a uniform C language, and is distributed with an "open source-compatible" license. I do not believe that the GPL or the Free Software Foundation's goals are near the top of the reasons for most users. If developers and users find that another free compiler satisfies those requirements better, I suspect developers and users would start migrating away. As Ian said, that ultimately would not hurt software freedom; it might hurt Free Software, and it definitely would hurt the GNU Project and the Free Software Foundation. David ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-16 17:16 ` David Edelsohn @ 2007-11-16 17:25 ` Dep, Khushil (GE Money) 2007-11-16 17:32 ` Tom Tromey 2007-11-17 14:15 ` Gabriel Dos Reis 0 siblings, 2 replies; 108+ messages in thread From: Dep, Khushil (GE Money) @ 2007-11-16 17:25 UTC (permalink / raw) To: David Edelsohn, Andrew Haley Cc: Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc -----Original Message----- From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of David Edelsohn Sent: 16 November 2007 16:58 To: Andrew Haley Cc: Ian Lance Taylor; Richard Kenner; dnovillo@google.com; Joe.Buck@synopsys.com; fleury@labri.fr; gcc@gcc.gnu.org Subject: Re: Progress on GCC plugins ? --snip-- -> The concern is not a first-order effect, but a second-order effect. GCC will improve more and faster if more developers are involved. ->Plug-ins will encourage more research and development of GCC -- more features and benefits. An improved GCC will attract more users. --snip-- I'm not sure that a plugin system will encourage more research and development. Anyone who even contemplates getting into the this field isn't going to be someone who is easily disuaded by challenges and obstacles. Anyone new to a system looks for clear concise documentation - something which the opensource world can lack! I believe efforts to clarify and expand documentation is much more likely to entice new researchers and developers rather than a plugin system which no doubt would be poorly documented! My 2c - have a good weekend all! -Khush. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:25 ` Dep, Khushil (GE Money) @ 2007-11-16 17:32 ` Tom Tromey 2007-11-17 14:15 ` Gabriel Dos Reis 1 sibling, 0 replies; 108+ messages in thread From: Tom Tromey @ 2007-11-16 17:32 UTC (permalink / raw) To: Dep, Khushil (GE Money) Cc: David Edelsohn, Andrew Haley, Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc >>>>> ">" == Dep, Khushil (GE Money) <Khushil.Dep@ge.com> writes: >> I believe efforts to clarify and expand documentation is much more >> likely to entice new researchers and developers rather than a >> plugin system which no doubt would be poorly documented! This idea comes up a lot. I'm sympathetic to it -- it would have been really useful to me, a couple years ago, if GCC had had better documentation. However, the two things are not tradeable. It isn't as if we are deciding what to do with limited manpower. GCC as a project basically cannot do that. Rather, we're deciding what changes to accept. There are existing patches to add plugins, and, presumably, the interest and manpower to polish and maintain them. Sadly, there aren't ready patches to radically upgrade the documentation. It doesn't make sense to reject plugin patches on the basis that documentation would be preferable. I find it unlikely that this will cause more documentation to be written. Instead, I think the likely effect is that GCC will lose some potential developers. Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:25 ` Dep, Khushil (GE Money) 2007-11-16 17:32 ` Tom Tromey @ 2007-11-17 14:15 ` Gabriel Dos Reis 2007-11-24 23:22 ` Alexandre Oliva 1 sibling, 1 reply; 108+ messages in thread From: Gabriel Dos Reis @ 2007-11-17 14:15 UTC (permalink / raw) To: Dep, Khushil (GE Money) Cc: David Edelsohn, Andrew Haley, Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc "Dep, Khushil (GE Money)" <Khushil.Dep@ge.com> writes: | I'm not sure that a plugin system will encourage more research and | development. Anyone who even contemplates getting into the this field | isn't going to be someone who is easily disuaded by challenges and | obstacles. I beg to disagree -- speaking from experience. The issue isn't `obstacle'; from my perspective, it is that of time and energy sunk into `mere re-invention of pointless wheels with no research result'. I had no trouble getting students up to spead on well-structured plugable proprietary compiler within weeks. However, the same experience on GCC has proven much less impressive results. Consequently, we have been making more progress working with proprietary compiler than with GCC -- something I find myself embarrasing :-( -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-17 14:15 ` Gabriel Dos Reis @ 2007-11-24 23:22 ` Alexandre Oliva 2007-11-24 23:29 ` Richard Kenner 2007-11-25 20:43 ` Tom Tromey 0 siblings, 2 replies; 108+ messages in thread From: Alexandre Oliva @ 2007-11-24 23:22 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Dep, Khushil (GE Money), David Edelsohn, Andrew Haley, Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc On Nov 17, 2007, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote: > I had no trouble getting students up to spead on well-structured > plugable proprietary compiler within weeks. However, the same > experience on GCC has proven much less impressive results. > Consequently, we have been making more progress working with > proprietary compiler than with GCC -- something I find myself > embarrasing :-( That's sad, but adding to GCC the ability to support plugins (I assume this is about dynamically-loaded GCC passes) won't change this at all. The thing that people have historically found difficult in getting started with GCC is that there was a lot of infrastructure that didn't follow the patterns and algorithms found in compiler literature. This has changed a bit with the Tree-SSA infrastructure, not only because SSA and GIMPLE-like representations are commonplace, but also because there aren't as many inter-dependencies and implicit assumptions between passes as there used to be with RTL. But it's still true that one has to learn a lot about GCC internals before one can write a new RTL pass, and even a new Tree-SSA pass. Merely introducing means for people to dynamically load passes won't change this. Only designing a plugin API that hides a lot of GCC's internal complexity, while still making room for useful experiments, would make this plugin API useful to address this problem. But then, this is much harder than just adding plugin support, and I'm familiar with any actual proposals that would address the underlying problem. And then, once the underlying problem is addressed and we have an API that is usable by regular users, maybe we will find out that we don't need plugins, after all. That, as Diego and Ian say, adding plugin support is trivial, but I'm pretty sure that's not where the actual problem lies. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-24 23:22 ` Alexandre Oliva @ 2007-11-24 23:29 ` Richard Kenner 2007-11-25 20:43 ` Tom Tromey 1 sibling, 0 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-24 23:29 UTC (permalink / raw) To: aoliva; +Cc: Joe.Buck, Khushil.Dep, aph, dje, dnovillo, fleury, gcc, gdr, iant > And then, once the underlying problem is addressed and we have an API > that is usable by regular users, maybe we will find out that we don't > need plugins, after all. That, as Diego and Ian say, adding plugin > support is trivial, but I'm pretty sure that's not where the actual > problem lies. That's my position as well. AND that plugin (here meaning dynamic link) support creates tricky legal issues that the RMS has not been willing to deal with in the past. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-24 23:22 ` Alexandre Oliva 2007-11-24 23:29 ` Richard Kenner @ 2007-11-25 20:43 ` Tom Tromey 2007-11-26 6:24 ` Taras Glek 1 sibling, 1 reply; 108+ messages in thread From: Tom Tromey @ 2007-11-25 20:43 UTC (permalink / raw) To: Alexandre Oliva; +Cc: gcc >>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes: Alexandre> And then, once the underlying problem is addressed and we Alexandre> have an API that is usable by regular users, maybe we will Alexandre> find out that we don't need plugins, after all. Plugins are about deployment, not development. Plugins make it possible to redistribute useful things which are not in GCC. They don't -- and as you rightly point out, can't -- make it simpler to actually develop these things. The canonical example, which has been covered many times, is a pass that does extra checking for a large program (e.g., Mozilla). LD_PRELOAD would work just as well as having gcc directly support plugins, provided that certain internal things are never made file-local. Someone could write a helper library to make it relatively simple to hook in. But... I looked at this recently, and since gcc is not linked with -rdynamic, it is a non-starter. Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-25 20:43 ` Tom Tromey @ 2007-11-26 6:24 ` Taras Glek 2007-11-26 19:49 ` Tom Tromey 0 siblings, 1 reply; 108+ messages in thread From: Taras Glek @ 2007-11-26 6:24 UTC (permalink / raw) To: tromey; +Cc: Alexandre Oliva, gcc Tom Tromey wrote: >>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes: >>>>>> > > Alexandre> And then, once the underlying problem is addressed and we > Alexandre> have an API that is usable by regular users, maybe we will > Alexandre> find out that we don't need plugins, after all. > > Plugins are about deployment, not development. > > Plugins make it possible to redistribute useful things which are not > in GCC. They don't -- and as you rightly point out, can't -- make it > simpler to actually develop these things. > > The canonical example, which has been covered many times, is a pass > that does extra checking for a large program (e.g., Mozilla). > There are a lot of checks that could be implemented as plugins to benefit Mozilla and other projects. For future Mozilla development certain features that we are looking at are not feasible in C++ until the compiler can help with enforcing correct API usage. It would be extremely awesome to be able to utilize GCC internals for static analysis and source refactoring. Currently that isn't realistic as these features do not belong in the GCC mainline and distributing a gcc fork would be very burdensome. Plugins would also encourage projects such as Mozilla to contribute to gcc to implement various backend improvements to make various plugins possible. I think GCC could gain some "accidental" contributors this way. i believe that this would also have an additional effect of making GCC the strongly suggested compiler for development as it would be able to provide development benefits not (yet?) available in most compilers. > > LD_PRELOAD would work just as well as having gcc directly support > plugins, provided that certain internal things are never made > file-local. Someone could write a helper library to make it > relatively simple to hook in. But... I looked at this recently, and > since gcc is not linked with -rdynamic, it is a non-starter. > Tom, I don't know much about linkers and LD_PRELOAD. Would making LD_PRELOAD work be easier than making an unstable plugin API? Taras ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-26 6:24 ` Taras Glek @ 2007-11-26 19:49 ` Tom Tromey 2007-11-26 21:31 ` Basile STARYNKEVITCH 0 siblings, 1 reply; 108+ messages in thread From: Tom Tromey @ 2007-11-26 19:49 UTC (permalink / raw) To: Taras Glek; +Cc: Alexandre Oliva, gcc >>>>> "Taras" == Taras Glek <taras.judge@shaw.ca> writes: Tom> LD_PRELOAD would work just as well as having gcc directly support Tom> plugins, provided that certain internal things are never made Tom> file-local. Someone could write a helper library to make it Tom> relatively simple to hook in. But... I looked at this recently, and Tom> since gcc is not linked with -rdynamic, it is a non-starter. Taras> Tom, I don't know much about linkers and LD_PRELOAD. Would making Taras> LD_PRELOAD work be easier than making an unstable plugin API? Not really. The difference would be that with LD_PRELOAD the gcc change would be very small -- just linking with -rdynamic. Maybe you could lobby a Linux distro for this :-) But even if the gcc change is small, you'd still want to write and maintain about the same amount of code to let plugins interface with the pass manager. Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-26 19:49 ` Tom Tromey @ 2007-11-26 21:31 ` Basile STARYNKEVITCH 2007-11-27 0:14 ` Tom Tromey 0 siblings, 1 reply; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-26 21:31 UTC (permalink / raw) To: Tom Tromey; +Cc: Taras Glek, gcc Tom Tromey wrote: >>>>>> "Taras" == Taras Glek <taras.judge@shaw.ca> writes: > > Tom> LD_PRELOAD would work just as well as having gcc directly support > Tom> plugins, provided that certain internal things are never made > Tom> file-local. Someone could write a helper library to make it > Tom> relatively simple to hook in. But... I looked at this recently, and > Tom> since gcc is not linked with -rdynamic, it is a non-starter. > > Taras> Tom, I don't know much about linkers and LD_PRELOAD. Would making > Taras> LD_PRELOAD work be easier than making an unstable plugin API? > > Not really. > > The difference would be that with LD_PRELOAD the gcc change would be > very small -- just linking with -rdynamic. Maybe you could lobby a > Linux distro for this :-) I'm not fully convinced that just LD_PRELOAD is enough to add poor man's plugin into GCC. Plugins into GCC are expected to add optimisation passes (see file gcc/passes.c function init_optimization_passes and I don't understand what exactly LD_PRELOAD trick (unless you also redefine this very function init_optimization_passes in your ld_preload-ed plugin) would enable this. So Tom or Taras, could you please elaborate on this? What tricks are you thinking of? However, you are right in the sense that implementing naive plugins is technically easy; apparently the issue is political, not technical (i.e. let RMS accept or bless it). -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-26 21:31 ` Basile STARYNKEVITCH @ 2007-11-27 0:14 ` Tom Tromey 2007-11-27 20:51 ` Alexandre Oliva 0 siblings, 1 reply; 108+ messages in thread From: Tom Tromey @ 2007-11-27 0:14 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: Taras Glek, gcc >>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes: Basile> Plugins into GCC are expected to add optimisation passes (see file Basile> gcc/passes.c function init_optimization_passes and I don't understand Basile> what exactly LD_PRELOAD trick (unless you also redefine this very Basile> function init_optimization_passes in your ld_preload-ed plugin) would Basile> enable this. FWIW I don't think this is an especially fruitful avenue of discussion. Let's take future conversation about LD_PRELOAD off-list. Basile> So Tom or Taras, could you please elaborate on this? What tricks are Basile> you thinking of? I think it isn't extremely hard for a preloaded .so to look up the pass list and dynamically modify it. This would be a big hack of course. I don't really recommend it. I do wonder if there is a platform out there that acts as if -rdynamic were the default. On such a platform you could already write plugins. Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-27 0:14 ` Tom Tromey @ 2007-11-27 20:51 ` Alexandre Oliva 2007-11-28 7:53 ` Ian Lance Taylor 0 siblings, 1 reply; 108+ messages in thread From: Alexandre Oliva @ 2007-11-27 20:51 UTC (permalink / raw) To: Tom Tromey; +Cc: Basile STARYNKEVITCH, Taras Glek, gcc On Nov 26, 2007, Tom Tromey <tromey@redhat.com> wrote: > I do wonder if there is a platform out there that acts as if -rdynamic > were the default. I'm pretty sure I was surprised when I first ran into the need for -rdynamic on GNU/Linux, because other platforms I'd used didn't need that. I'd guess that would have been SunOS4.1.3 or maybe Solaris2.1, back then. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-27 20:51 ` Alexandre Oliva @ 2007-11-28 7:53 ` Ian Lance Taylor 0 siblings, 0 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-28 7:53 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Tom Tromey, Basile STARYNKEVITCH, Taras Glek, gcc Alexandre Oliva <aoliva@redhat.com> writes: > On Nov 26, 2007, Tom Tromey <tromey@redhat.com> wrote: > > > I do wonder if there is a platform out there that acts as if -rdynamic > > were the default. > > I'm pretty sure I was surprised when I first ran into the need for > -rdynamic on GNU/Linux, because other platforms I'd used didn't need > that. I'd guess that would have been SunOS4.1.3 or maybe Solaris2.1, > back then. -rdynamic was the default on SunOS and on SVR4. It was not the default on Solaris. It is not the default for the GNU linker because I was copying the Solaris linker. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:56 ` Ian Lance Taylor 2007-11-16 16:58 ` Diego Novillo 2007-11-16 17:08 ` Andrew Haley @ 2007-11-16 17:18 ` Richard Kenner 2007-11-16 17:27 ` Joe Buck ` (2 more replies) 2 siblings, 3 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-16 17:18 UTC (permalink / raw) To: iant; +Cc: Joe.Buck, aph, dnovillo, fleury, gcc > I have a different fear: that gcc will become increasing irrelevant, > as more and more new programmers learn to work on alternative free > compilers instead. That is neutral with regard to freedom, but it > will tend to lose the many years of experience which have been put > into gcc. In my view, if we can't even get ourselves together to > permit something as simple as plugins with an unstable API, then we > deserve to lose. As was said before, the difficultly in people working with GCC is primarily lack of adequate documentation. Creating a "plugin" interface is certainly much more fun than writing documentation, but doesn't help this issue nearly as much. Moreover, writing documentation is not a potential legal threat while plugins are. To me, that argues strongly against plugins and in favor of much more documentation. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:18 ` Richard Kenner @ 2007-11-16 17:27 ` Joe Buck 2007-11-16 17:31 ` Basile STARYNKEVITCH 2007-11-16 18:54 ` Diego Novillo 2 siblings, 0 replies; 108+ messages in thread From: Joe Buck @ 2007-11-16 17:27 UTC (permalink / raw) To: Richard Kenner; +Cc: iant, aph, dnovillo, fleury, gcc On Fri, Nov 16, 2007 at 12:02:44PM -0500, Richard Kenner wrote: > As was said before, the difficultly in people working with GCC is > primarily lack of adequate documentation. Creating a "plugin" interface > is certainly much more fun than writing documentation, but doesn't help > this issue nearly as much. Moreover, writing documentation is not a > potential legal threat while plugins are. To me, that argues strongly > against plugins and in favor of much more documentation. More documentation: a good thing. Contributions welcome. Plugins a potential legal threat: you must be using "legal threat" in some strange way I don't understand, but I don't see them as a threat at all. In any case, the two issues are orthogonal. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:18 ` Richard Kenner 2007-11-16 17:27 ` Joe Buck @ 2007-11-16 17:31 ` Basile STARYNKEVITCH 2007-11-16 17:38 ` Joe Buck 2007-11-16 18:54 ` Diego Novillo 2 siblings, 1 reply; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-16 17:31 UTC (permalink / raw) Cc: gcc Richard Kenner wrote: > > As was said before, the difficultly in people working with GCC is > primarily lack of adequate documentation. I am not sure of that. GCC is a huge piece of software. This is the major difficulty: grasping a 3MLOC software whose source is available, rather well commented, with some documentation (I agree it could be better; feel free to add it at least on the wiki). Compare this to the Linux kernel (which I do not know in detail). While it might be more documented in the source tree, it is certainly more documented outside (there are several good books on kernel internals; I'm not sure that equivalent books for GCC exist, and I would spend 50 euros -of my own money- for such a book if it existed). And still, diving and contributing to the Linux kernel and/or to GCC is really hard (I admit I don't know what is harder, and probably nobody knows both software in the same details!). The biggest barrier to working on GCC is a learning & working effort barrier. I don't think documentation would help a lot (and maintaining it is a nightmare). I am not sure (I really don't know) if more documentation on GCC exist, even inside companies with teams of a dozen of talented GCC contributors. I don't believe (maybe I am wrong) that for instance IBM or Google or AMD (or any company with several GCC developers full time) have a lot of (maybe proprietary) internal documentation on GCC. I even don't believe that competitor proprietary compilers are much more documented than GCC. GCC is an incredibly complex software (because any similar compiler has to be complex and huge). PS. My mentor on GCC has been Sebastian Pop. I'll never thank him enough! -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:31 ` Basile STARYNKEVITCH @ 2007-11-16 17:38 ` Joe Buck 2007-11-16 19:21 ` Gerald.Williams 0 siblings, 1 reply; 108+ messages in thread From: Joe Buck @ 2007-11-16 17:38 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: gcc On Fri, Nov 16, 2007 at 06:15:50PM +0100, Basile STARYNKEVITCH wrote: > I even don't believe that competitor proprietary compilers are much more > documented than GCC. Depends. Vendors of compiler front ends (those sold for extension by others) provide very good documentation, much better than any that GCC has; this is necessary since they are sold to be extended by the buyer. I won't name names because it's inappropriate to plug proprietary software on this list. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-16 17:38 ` Joe Buck @ 2007-11-16 19:21 ` Gerald.Williams 2007-11-16 19:58 ` Joe Buck 0 siblings, 1 reply; 108+ messages in thread From: Gerald.Williams @ 2007-11-16 19:21 UTC (permalink / raw) To: gcc Much as I hate prolonging a probably-pointless discussion... I hope we aren't thinking about keeping things difficult for everybody simply because everybody includes some people who may want to take advantage of GCC in a proprietary way. In the long term, this only benefits the folks you'd be trying to exclude. Think about it. You have nothing to fear from people writing trivial add-ons (if they're useful, they'll be duplicated in open source; if not, they'll fade away). The only people you might need to worry about would be those writing significant new compiler designs/enhancements using GCC as a starting point (and possibly trying to get past the GPL by avoiding direct linking/etc.). Yet as has already been pointed out, they already can do this by creating their own interface to plug into. If they use a standard interface (since the code base would favor this), it would be easier to replace their plug-ins with open-source alternatives later. -Jerry ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 19:21 ` Gerald.Williams @ 2007-11-16 19:58 ` Joe Buck 2007-11-16 21:43 ` Gerald.Williams 0 siblings, 1 reply; 108+ messages in thread From: Joe Buck @ 2007-11-16 19:58 UTC (permalink / raw) To: Gerald.Williams; +Cc: gcc On Fri, Nov 16, 2007 at 07:29:12PM +0100, Gerald.Williams@infineon.com wrote: > I hope we aren't thinking about keeping things difficult for > everybody simply because everybody includes some people who > may want to take advantage of GCC in a proprietary way. In > the long term, this only benefits the folks you'd be trying > to exclude. RMS believes that people who extend GCC, hoping to take their extensions proprietary, and then finding that they can't, will then just decide to contribute the code, if it is useful, since otherwise they can't distribute and have to support it by themselves forever, or else they have to risk legal problems. And he has some evidence that this sometimes happens (C++, Objective-C, many contributed back ends). So the intent isn't to prevent certain people from using it, but to have those people contribute the changes back even if that isn't their preference. Now that's fine as far as it goes, but when it becomes a defense of an opaque, non-extendable architecture we have a problem. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-16 19:58 ` Joe Buck @ 2007-11-16 21:43 ` Gerald.Williams 0 siblings, 0 replies; 108+ messages in thread From: Gerald.Williams @ 2007-11-16 21:43 UTC (permalink / raw) To: gcc Joe Buck wrote: > RMS believes that people who extend GCC, hoping to take their extensions > proprietary, and then finding that they can't, will then just decide to > contribute the code, if it is useful, since otherwise they can't > distribute and have to support it by themselves forever, or else they have > to risk legal problems. And he has some evidence that this sometimes > happens (C++, Objective-C, many contributed back ends). So the intent > isn't to prevent certain people from using it, but to have those people > contribute the changes back even if that isn't their preference. > > Now that's fine as far as it goes, but when it becomes a defense > of an opaque, non-extendable architecture we have a problem. Agreed. It can also make it harder to contribute changes back, thus possibly precluding some contributions. -Jerry ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:18 ` Richard Kenner 2007-11-16 17:27 ` Joe Buck 2007-11-16 17:31 ` Basile STARYNKEVITCH @ 2007-11-16 18:54 ` Diego Novillo 2007-11-16 19:13 ` Martin Jambor 2007-11-18 22:12 ` Robert Dewar 2 siblings, 2 replies; 108+ messages in thread From: Diego Novillo @ 2007-11-16 18:54 UTC (permalink / raw) To: Richard Kenner; +Cc: iant, Joe.Buck, aph, fleury, gcc Richard Kenner wrote: >> I have a different fear: that gcc will become increasing irrelevant, >> as more and more new programmers learn to work on alternative free >> compilers instead. That is neutral with regard to freedom, but it >> will tend to lose the many years of experience which have been put >> into gcc. In my view, if we can't even get ourselves together to >> permit something as simple as plugins with an unstable API, then we >> deserve to lose. > > As was said before, the difficultly in people working with GCC is > primarily lack of adequate documentation. Creating a "plugin" interface > is certainly much more fun than writing documentation, but doesn't help > this issue nearly as much. Moreover, writing documentation is not a > potential legal threat while plugins are. To me, that argues strongly > against plugins and in favor of much more documentation. No, this argument is fallacious. Plug-ins and poor documentation are not, and should not be related. Poor documentation is an orthogonal problem which ALSO needs to be addressed. The existence of a plug-in framework with bad/no documentation does not make working with GCC any easier. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 18:54 ` Diego Novillo @ 2007-11-16 19:13 ` Martin Jambor 2007-11-18 22:12 ` Robert Dewar 1 sibling, 0 replies; 108+ messages in thread From: Martin Jambor @ 2007-11-16 19:13 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Kenner, iant, Joe.Buck, aph, fleury, gcc Hi, On Nov 16, 2007 6:45 PM, Diego Novillo <dnovillo@google.com> wrote: > Richard Kenner wrote: > > As was said before, the difficultly in people working with GCC is > > primarily lack of adequate documentation. Creating a "plugin" interface > > is certainly much more fun than writing documentation, but doesn't help > > this issue nearly as much. Moreover, writing documentation is not a > > potential legal threat while plugins are. To me, that argues strongly > > against plugins and in favor of much more documentation. > > No, this argument is fallacious. Plug-ins and poor documentation are > not, and should not be related. Poor documentation is an orthogonal > problem which ALSO needs to be addressed. I brought up the documentation in this debate so let me clarify what I meant. I simply wanted to tell that you cannot expect that plugins are going to make life easier for newcomers. If that is your goal, you have to do something else. On the contrary, I have acknowledged there might be other and very beneficial reasons for having such a framework like the static analysis tools which I know nothing about. The conclusion is that the arguments in favor of plugins should concentrate on these technical advantages rather than on research. Such arguments, if explained a bit more thoroughly, might indeed be very interesting to hear (read). Finally, I also do not think plugins would all of a sudden allow anyone to hijack the compiler more easily than it is possible today. Martin ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 18:54 ` Diego Novillo 2007-11-16 19:13 ` Martin Jambor @ 2007-11-18 22:12 ` Robert Dewar 2007-11-19 4:16 ` Gabriel Dos Reis 1 sibling, 1 reply; 108+ messages in thread From: Robert Dewar @ 2007-11-18 22:12 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Kenner, iant, Joe.Buck, aph, fleury, gcc Diego Novillo wrote: > No, this argument is fallacious. Plug-ins and poor documentation are > not, and should not be related. Poor documentation is an orthogonal > problem which ALSO needs to be addressed. Actually to me if you have plug-ins, good documentation of the plug-in interface is absolutely essential, so I am a bit cooncerned to hear of people eager to program plugin facilities, and at the same time hear that people are reluctant to document. It's interestinng to note that in the Ada world, there is an ISO standard for plugins, which is compiler/vendor neutral (at least in theory, in practice there are some implementation dependencies). That's the ASIS interface (Ada Semantic Interface Specification). > > The existence of a plug-in framework with bad/no documentation does not > make working with GCC any easier. > > > Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-18 22:12 ` Robert Dewar @ 2007-11-19 4:16 ` Gabriel Dos Reis 2007-11-19 4:23 ` Richard Kenner ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: Gabriel Dos Reis @ 2007-11-19 4:16 UTC (permalink / raw) To: Robert Dewar Cc: Diego Novillo, Richard Kenner, iant, Joe.Buck, aph, fleury, gcc Robert Dewar <dewar@adacore.com> writes: | It's interestinng to note that in the Ada world, there is an ISO | standard for plugins, which is compiler/vendor neutral (at least | in theory, in practice there are some implementation dependencies). | That's the ASIS interface (Ada Semantic Interface Specification). So, is it that plugins are good for Ada (and I presume the GNU Ada front end) but not for GCC? -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 4:16 ` Gabriel Dos Reis @ 2007-11-19 4:23 ` Richard Kenner 2007-11-19 9:11 ` Robert Dewar 2007-11-19 8:26 ` Robert Dewar 2007-11-19 8:37 ` Robert Dewar 2 siblings, 1 reply; 108+ messages in thread From: Richard Kenner @ 2007-11-19 4:23 UTC (permalink / raw) To: gdr; +Cc: Joe.Buck, aph, dewar, dnovillo, fleury, gcc, iant > Robert Dewar <dewar@adacore.com> writes: > > | It's interestinng to note that in the Ada world, there is an ISO > | standard for plugins, which is compiler/vendor neutral (at least > | in theory, in practice there are some implementation dependencies). > | That's the ASIS interface (Ada Semantic Interface Specification). > > So, is it that plugins are good for Ada (and I presume the GNU Ada > front end) but not for GCC? Robert is using the word "plugin" differently. ASIS is an interface and a library. There are no plugins in the sense discussed here. He means it in a very generic sense, in the sense that we already have it for GCC. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 4:23 ` Richard Kenner @ 2007-11-19 9:11 ` Robert Dewar 2007-11-19 9:49 ` Richard Kenner ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-19 9:11 UTC (permalink / raw) To: Richard Kenner; +Cc: gdr, Joe.Buck, aph, dnovillo, fleury, gcc, iant Richard Kenner wrote: >> Robert Dewar <dewar@adacore.com> writes: >> >> | It's interestinng to note that in the Ada world, there is an ISO >> | standard for plugins, which is compiler/vendor neutral (at least >> | in theory, in practice there are some implementation dependencies). >> | That's the ASIS interface (Ada Semantic Interface Specification). >> >> So, is it that plugins are good for Ada (and I presume the GNU Ada >> front end) but not for GCC? > > Robert is using the word "plugin" differently. ASIS is an interface > and a library. There are no plugins in the sense discussed here. He > means it in a very generic sense, in the sense that we already have it > for GCC. So I am not sure I understand Richard's points above, so let me be clear about what ASIS is. It is a set of libraries, and a well defined API, that allows generic tools to be written that have full access to the semantic information discovered by the compiler. This API is fully documented and defined in a compiler-neutral form. I am not at all clear that we have ANYTHING like that for GCC, so I am completely puzzled by Richard's last remark. Let's take an example, suppose we want to write a semantic analysis tool (e.g. the Mozilla style checker mentioned earlier). For Ada, we can write an ASIS application and we need to know NOTHING AT ALL about the internals of the compiler we are using, we only read the ASIS documentation. Indeed we could start writing that tool before we decided which Ada commpiler we would use. I know of nothing vaguely equivalent to this in the general gcc context, am I really missing something that big? On the other hand, if your mission is to plug in an extra optimization pass, ASIS won't help since it is strictly a read-only interface with no provision for feeding back information to the compiler. It is theoretically possible to write a compiler back end using the ASIS interface, but in practice I think this would be an extremely difficult task. For sure it has never happened so far. What is interesting is that ASIS provides a well-defined clearly legally-ok interface from the commpiler to proprietary tools, and there are a number of proprietary ASIS tools on the market. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 9:11 ` Robert Dewar @ 2007-11-19 9:49 ` Richard Kenner 2007-11-19 10:21 ` Robert Dewar 2007-11-19 12:14 ` Gabriel Dos Reis 2007-11-19 12:28 ` Gabriel Dos Reis 2 siblings, 1 reply; 108+ messages in thread From: Richard Kenner @ 2007-11-19 9:49 UTC (permalink / raw) To: dewar; +Cc: Joe.Buck, aph, dnovillo, fleury, gcc, gdr, iant > So I am not sure I understand Richard's points above, so let me be clear > about what ASIS is. > > It is a set of libraries, and a well defined API, that allows generic > tools to be written that have full access to the semantic information > discovered by the compiler. This API is fully documented and defined > in a compiler-neutral form. > > I am not at all clear that we have ANYTHING like that for GCC, so I > am completely puzzled by Richard's last remark. The discussion here is competely different. The issue isn't the interface, but the mechanism of how it's called. A "plugin" here means a module that would be dynamically loaded by GCC, as opposed to being linked in to the compiler statically. In other words, once a plugin mechanism exists, it's possible to add passes to GCC without having to change the compiler at all. The analogy are the plugins to Mozilla. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 9:49 ` Richard Kenner @ 2007-11-19 10:21 ` Robert Dewar 0 siblings, 0 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-19 10:21 UTC (permalink / raw) To: Richard Kenner; +Cc: Joe.Buck, aph, dnovillo, fleury, gcc, gdr, iant Richard Kenner wrote: >> So I am not sure I understand Richard's points above, so let me be clear >> about what ASIS is. >> >> It is a set of libraries, and a well defined API, that allows generic >> tools to be written that have full access to the semantic information >> discovered by the compiler. This API is fully documented and defined >> in a compiler-neutral form. >> >> I am not at all clear that we have ANYTHING like that for GCC, so I >> am completely puzzled by Richard's last remark. > > The discussion here is competely different. The issue isn't the interface, > but the mechanism of how it's called. > > A "plugin" here means a module that would be dynamically loaded by GCC, as > opposed to being linked in to the compiler statically. In other words, > once a plugin mechanism exists, it's possible to add passes to GCC without > having to change the compiler at all. The analogy are the plugins to Mozilla. Sure, that's the *mechanism* but the usage of such a plug-in will be varied. As is clear from this long thread, people have many ideas of what might be done with such a plugin a) separate (propietary?) back end .. could conceivably be done using ASIS. b) separate analysis tool (e.g. Mozilla style rules) could most certainly be done with ASIS. c) new optimization pass -- out of range for ASIS. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 9:11 ` Robert Dewar 2007-11-19 9:49 ` Richard Kenner @ 2007-11-19 12:14 ` Gabriel Dos Reis 2007-11-19 12:28 ` Gabriel Dos Reis 2 siblings, 0 replies; 108+ messages in thread From: Gabriel Dos Reis @ 2007-11-19 12:14 UTC (permalink / raw) To: Robert Dewar; +Cc: Richard Kenner, Joe.Buck, aph, dnovillo, fleury, gcc, iant On Sun, 18 Nov 2007, Robert Dewar wrote: | Richard Kenner wrote: | > > Robert Dewar <dewar@adacore.com> writes: | > > | > > | It's interestinng to note that in the Ada world, there is an ISO | > > | standard for plugins, which is compiler/vendor neutral (at least | > > | in theory, in practice there are some implementation dependencies). | > > | That's the ASIS interface (Ada Semantic Interface Specification). | > > | > > So, is it that plugins are good for Ada (and I presume the GNU Ada | > > front end) but not for GCC? | > | > Robert is using the word "plugin" differently. ASIS is an interface | > and a library. There are no plugins in the sense discussed here. He | > means it in a very generic sense, in the sense that we already have it | > for GCC. | | So I am not sure I understand Richard's points above, so let me be clear | about what ASIS is. | | It is a set of libraries, and a well defined API, that allows generic | tools to be written that have full access to the semantic information | discovered by the compiler. This API is fully documented and defined | in a compiler-neutral form. Yes, I'm familiar with ASIS, ANNA, etc. And Yes, Kenner's point sound a bit strange to me, but then, this whole discussion seems so strange to me to have given the current situation in 2007. -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 9:11 ` Robert Dewar 2007-11-19 9:49 ` Richard Kenner 2007-11-19 12:14 ` Gabriel Dos Reis @ 2007-11-19 12:28 ` Gabriel Dos Reis 2007-11-19 13:18 ` Robert Dewar 2 siblings, 1 reply; 108+ messages in thread From: Gabriel Dos Reis @ 2007-11-19 12:28 UTC (permalink / raw) To: Robert Dewar; +Cc: Richard Kenner, Joe.Buck, aph, dnovillo, fleury, gcc, iant On Sun, 18 Nov 2007, Robert Dewar wrote: | Let's take an example, suppose we want to write a semantic analysis | tool (e.g. the Mozilla style checker mentioned earlier). For Ada, | we can write an ASIS application and we need to know NOTHING AT ALL | about the internals of the compiler we are using, we only read the | ASIS documentation. Indeed we could start writing that tool before | we decided which Ada commpiler we would use. | | I know of nothing vaguely equivalent to this in the general gcc | context, am I really missing something that big? I have been able to build similar tool for at least two radically different C++ front ends -- one being proprietary, the other one being GCC (the most painful to work with). We call the representation `IPR' (for Internal Program Representation). The interface is completely compiler neutral. I haven't tested it myself on another important proprietary compiler but from feedback people we talked with, we should not worry. Yes, that is not an ISO-approved thing, but just a data point something `vaguely equivalent to this in the general g++' context has been done. We have not released IPR yet, but it be open source a fairly open license. | On the other hand, if your mission is to plug in an extra optimization | pass, ASIS won't help since it is strictly a read-only interface with | no provision for feeding back information to the compiler. IPR doesn't attempt to replace compiler internal data structures for writing optimizations. Nor it is a plugin into GIMPLE or RTL -- as I said, it is designed to be compiler neutral. -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 12:28 ` Gabriel Dos Reis @ 2007-11-19 13:18 ` Robert Dewar 0 siblings, 0 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-19 13:18 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Richard Kenner, Joe.Buck, aph, dnovillo, fleury, gcc, iant Gabriel Dos Reis wrote: > I have been able to build similar tool for at least two radically > different C++ front ends -- one being proprietary, the other one > being GCC (the most painful to work with). We call the representation > `IPR' (for Internal Program Representation). The interface is > completely compiler neutral. I haven't tested it myself on another > important proprietary compiler but from feedback people we talked > with, we should not worry. Yes, that is not an ISO-approved thing, > but just a data point something `vaguely equivalent to this in the > general g++' context has been done. We have not released IPR yet, but > it be open source a fairly open license. It would be great if this could be the basis for an ASIS-similar standard for C++, even if it is only a de factor semi-standard :-) > > | On the other hand, if your mission is to plug in an extra optimization > | pass, ASIS won't help since it is strictly a read-only interface with > | no provision for feeding back information to the compiler. > > IPR doesn't attempt to replace compiler internal data structures for > writing optimizations. Nor it is a plugin into GIMPLE or RTL -- as I > said, it is designed to be compiler neutral. > > -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 4:16 ` Gabriel Dos Reis 2007-11-19 4:23 ` Richard Kenner @ 2007-11-19 8:26 ` Robert Dewar 2007-11-19 8:37 ` Robert Dewar 2 siblings, 0 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-19 8:26 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Diego Novillo, Richard Kenner, iant, Joe.Buck, aph, fleury, gcc Gabriel Dos Reis wrote: > Robert Dewar <dewar@adacore.com> writes: > > | It's interestinng to note that in the Ada world, there is an ISO > | standard for plugins, which is compiler/vendor neutral (at least > | in theory, in practice there are some implementation dependencies). > | That's the ASIS interface (Ada Semantic Interface Specification). > > So, is it that plugins are good for Ada (and I presume the GNU Ada > front end) but not for GCC? Well remember that the starting point in Ada that makes the plugin useful is the ISO standard which achieves several things: a) uniformity across different vendor implementations. It is possible to write a semantic analysis tool that will run with GNAT or with other Ada compilers implementing ASIS. b) full formal documentation of the interface Note that the existence of b) means clearly that the interface is not proprietary, and in the case of GNAT not associated with the GPL in any way in my non-lawyer, but offically-court-expert view. There is a big difference between standard interfaces of this kind and cooked up interfaces between two programs that are dependent on one another to form a complete product. To me it is premature to implement any kind of plug in without complete documentation that gets extensively reviewed in advance of any implementation, so I would hesitate to use the Ada ASIS approach as justification for cooking up some idiosyncratic not-completely-well-documented interface for gcc. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-19 4:16 ` Gabriel Dos Reis 2007-11-19 4:23 ` Richard Kenner 2007-11-19 8:26 ` Robert Dewar @ 2007-11-19 8:37 ` Robert Dewar 2 siblings, 0 replies; 108+ messages in thread From: Robert Dewar @ 2007-11-19 8:37 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Diego Novillo, Richard Kenner, iant, Joe.Buck, aph, fleury, gcc Gabriel Dos Reis wrote: > Robert Dewar <dewar@adacore.com> writes: > > | It's interestinng to note that in the Ada world, there is an ISO > | standard for plugins, which is compiler/vendor neutral (at least > | in theory, in practice there are some implementation dependencies). > | That's the ASIS interface (Ada Semantic Interface Specification). > > So, is it that plugins are good for Ada (and I presume the GNU Ada > front end) but not for GCC? All versions of the GNAT front end can produce the trees needed as INPUT to the ASIS library (these trees are reasonably documented, see sinfo and einfo, but nothing like formally documented at the standards level). The ASIS library itself is not part of the FSF sources, because that would seem contrary to the general GCC goal of discouraging proprietary coupling. > > -- Gaby ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:18 ` Ian Lance Taylor 2007-11-16 16:21 ` Andrew Haley @ 2007-11-16 16:24 ` Basile STARYNKEVITCH 2007-11-16 17:03 ` Ian Lance Taylor 2007-11-16 19:09 ` Martin Michlmayr 2 siblings, 1 reply; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-16 16:24 UTC (permalink / raw) To: gcc Ian Lance Taylor wrote: > But as you know, most gcc ports are never contributed anyhow. Naively, I didn't know that! I thought most ports were contributed, but some rejected because of code quality, lack of reviewers, etc.... But does these ports are published elsewhere, in the spirit of GPL, or are there distributed in a fully proprietary & binary only way (hence violating the GPL)? > Ports > that people hire Red Hat to do are contributed, but I can easily count > six gcc ports I've seen myself that were never contributed. So again > I don't see a substantive difference here. Regarding GCC plugins, and in contrast to some, I still view them as a big progress (avoiding a make bootstrap is already significant). In particular, a GCC plugin machinery permit quicker experimentation of new stuff, and also would perhaps permit inclusion of some specialized code (like static analysis) which won't fit in the trunk easily. Of course it is bound by the GPL and should be GPL. There is one (minor, & insignificant in my opinion) argument against dynamic plugins: they require a dynamic loading machinery (typically the libdl, dlopen or equivalent libtldl) which in principle could be unavailable on some bizarre hosts (but I don't know of anymore such host) In other words, they require additional features than the theoretical plain C ANSI compiler. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:24 ` Basile STARYNKEVITCH @ 2007-11-16 17:03 ` Ian Lance Taylor 0 siblings, 0 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-16 17:03 UTC (permalink / raw) To: Basile STARYNKEVITCH; +Cc: gcc Basile STARYNKEVITCH <basile@starynkevitch.net> writes: > Ian Lance Taylor wrote: > > But as you know, most gcc ports are never contributed anyhow. > > Naively, I didn't know that! > I thought most ports were contributed, but some rejected because of > code quality, lack of reviewers, etc.... > > But does these ports are published elsewhere, in the spirit of GPL, or > are there distributed in a fully proprietary & binary only way (hence > violating the GPL)? Fallacy of the excluded middle. I'm not aware of anybody who violates the GPL when distributing gcc. But the GPL permits private distribution: if you give people both the binaries and the sources, you have satisfied the requirements of the GPL. That is what happens with private gcc ports: the companies distribute the modified compiler to their customers, but not to the public at large. Under the terms of the GPL, their customers are of course free to distribute the compiler to anybody they choose. In practice, they don't bother; why should they? > There is one (minor, & insignificant in my opinion) argument against > dynamic plugins: they require a dynamic loading machinery (typically > the libdl, dlopen or equivalent libtldl) which in principle could be > unavailable on some bizarre hosts (but I don't know of anymore such > host) In other words, they require additional features than the > theoretical plain C ANSI compiler. Yes. But in practice they can work on GNU/Linux, all Unix systems, Windows, and MacOS, so I don't think this is a major concern. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 16:18 ` Ian Lance Taylor 2007-11-16 16:21 ` Andrew Haley 2007-11-16 16:24 ` Basile STARYNKEVITCH @ 2007-11-16 19:09 ` Martin Michlmayr 2007-11-16 20:27 ` Ian Lance Taylor 2 siblings, 1 reply; 108+ messages in thread From: Martin Michlmayr @ 2007-11-16 19:09 UTC (permalink / raw) To: Ian Lance Taylor Cc: Andrew Haley, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc * Ian Lance Taylor <iant@google.com> [2007-11-16 07:49]: > But as you know, most gcc ports are never contributed anyhow. Ports > that people hire Red Hat to do are contributed, but I can easily > count six gcc ports I've seen myself that were never contributed. Can you list those six ports? Has anyone tried to talk to those people to get them to contribute? -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 19:09 ` Martin Michlmayr @ 2007-11-16 20:27 ` Ian Lance Taylor 0 siblings, 0 replies; 108+ messages in thread From: Ian Lance Taylor @ 2007-11-16 20:27 UTC (permalink / raw) To: Martin Michlmayr; +Cc: gcc Martin Michlmayr <tbm@cyrius.com> writes: > * Ian Lance Taylor <iant@google.com> [2007-11-16 07:49]: > > But as you know, most gcc ports are never contributed anyhow. Ports > > that people hire Red Hat to do are contributed, but I can easily > > count six gcc ports I've seen myself that were never contributed. > > Can you list those six ports? Has anyone tried to talk to those > people to get them to contribute? C2 Microsystems Jazz C2 Microsystems ENE Cray X-2 Cradle Technologies DSE A processor from a Japanese company which I have forgotten, maybe Toshiba and, OK, I thought I had seen six but now I can only remember five There are also routinely messages on gcc-help referring to private ports which I have not seen myself. The truth is, there is no real advantage to anybody for these ports to be contributed. They often have machine specific changes to the machine independent parts of gcc, which would have to be managed somehow. These are not popular processors. Nobody outside the manufacturer has the knowledge or interest to maintain the backends. We've seen plenty of cases where a backend was contributed and then dropped a couple of years later. These would just be more of the same. Ian ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:04 ` Ian Lance Taylor 2007-11-15 22:46 ` Richard Kenner 2007-11-15 22:53 ` Andrew Haley @ 2007-11-16 0:01 ` Emmanuel Fleury 2007-11-16 17:27 ` Bernd Schmidt 3 siblings, 0 replies; 108+ messages in thread From: Emmanuel Fleury @ 2007-11-16 0:01 UTC (permalink / raw) To: gcc Ian Lance Taylor wrote: > > I think it's quite important for gcc's long-term health to permit and > even encourage academic researchers and students to use it. And I see > plugins as directly supporting that goal. Note that I don't see any > problem with requiring (or attempting to require) that any plugin be > covered by the GPL. Not only this but I'm also more and more concerned about closed source static analysis and code verification tools such as Coverity (http://www.coverity.com/), SLAM (http://research.microsoft.com/slam/) and others (see the list on Wikipedia: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis). If our concern in the 90's was to build code with an open source compiler, our concern nowadays should be to produce better code inside the open source community... Not having a common open source toolkit to perform *advanced* analysis of code and to build software on it will ends up having an unbalanced quality between proprietary and open source projects in a very unfair manner. We are now only at the beginning of the rise of these tools and yet it makes quite a difference between the code quality of projects using it or not... Having GCC to provide plug-ins would (in my humble opinion) indirectly boost code quality in open source development by allowing better tools to appears and help to fill the gap that started to appear between proprietary and open source code. Moreover, considering the GCC developers point-of-view, it becomes more and more obvious (at least to me) that the next 'frontier' in modern compiler design will be to export features to perform static analysis and verification on code. At last, I would say that I'm more concerned about the number of closed source tools to perform code analysis (with or without the help of GCC) than the hypothetical use of GCC by proprietary softwares because not having this analysis tools will make us loose the race anyway... Well, of course, this is only my very personal point of view on this topic... :) Regards -- Emmanuel Fleury Research is an organized method for keeping you reasonably dissatisfied with what you have. -- Charles Kettering ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:04 ` Ian Lance Taylor ` (2 preceding siblings ...) 2007-11-16 0:01 ` Emmanuel Fleury @ 2007-11-16 17:27 ` Bernd Schmidt 2007-11-16 17:35 ` Richard Kenner ` (4 more replies) 3 siblings, 5 replies; 108+ messages in thread From: Bernd Schmidt @ 2007-11-16 17:27 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Ian Lance Taylor wrote: > I think it's quite important for gcc's long-term health to permit and > even encourage academic researchers and students to use it. And I see > plugins as directly supporting that goal. Note that I don't see any > problem with requiring (or attempting to require) that any plugin be > covered by the GPL. > > So from my perspective the downside of plugins is very small, and the > upside is very large. I must admit I don't understand the upside. I've always thought of plugins as something proprietary programs need because their source isn't open. In my view, plugins will bitrot quickly as GCC's interface changes; and they won't even help with the learning curve - does anyone believe for a second you won't have to understand compiler internals to write a plugin? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:27 ` Bernd Schmidt @ 2007-11-16 17:35 ` Richard Kenner 2007-11-16 18:41 ` Dave Korn 2007-11-16 17:46 ` Basile STARYNKEVITCH ` (3 subsequent siblings) 4 siblings, 1 reply; 108+ messages in thread From: Richard Kenner @ 2007-11-16 17:35 UTC (permalink / raw) To: bernds_cb1; +Cc: Joe.Buck, dnovillo, fleury, gcc, iant > I must admit I don't understand the upside. I've always thought of > plugins as something proprietary programs need because their source > isn't open. > > In my view, plugins will bitrot quickly as GCC's interface changes; and > they won't even help with the learning curve - does anyone believe for a > second you won't have to understand compiler internals to write a plugin? I agree. I don't understand the upside either, for the same reasons. If I want to test some piece of code in the compiler, I don't have to bootstrap with or without plugins (unless I need to for testing purposes). The only difference is how I link, which seems a completely trivial distinction to me. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Progress on GCC plugins ? 2007-11-16 17:35 ` Richard Kenner @ 2007-11-16 18:41 ` Dave Korn 0 siblings, 0 replies; 108+ messages in thread From: Dave Korn @ 2007-11-16 18:41 UTC (permalink / raw) To: 'Richard Kenner', bernds_cb1 Cc: Joe.Buck, dnovillo, fleury, gcc, iant On 16 November 2007 17:25, Richard Kenner wrote: > If I want to test some piece of code in the compiler, I don't have to > bootstrap with or without plugins (unless I need to for testing purposes). > The only difference is how I link, which seems a completely trivial > distinction to me. That seems, on the face of it, a specious argument. It's only true because you have already in the past bootstrapped the compiler and kept the build directory lying around. Saying "I don't have to bootstrap because I've already done it" doesn't justify your claim that it's no easier or harder for new developers (who haven't got $objdir kicking around already). cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:27 ` Bernd Schmidt 2007-11-16 17:35 ` Richard Kenner @ 2007-11-16 17:46 ` Basile STARYNKEVITCH 2007-11-16 17:52 ` Joe Buck ` (2 subsequent siblings) 4 siblings, 0 replies; 108+ messages in thread From: Basile STARYNKEVITCH @ 2007-11-16 17:46 UTC (permalink / raw) To: gcc Bernd Schmidt wrote: > Ian Lance Taylor wrote: > >> I think it's quite important for gcc's long-term health to permit and >> even encourage academic researchers and students to use it. And I see >> plugins as directly supporting that goal. Note that I don't see any >> problem with requiring (or attempting to require) that any plugin be >> covered by the GPL. >> >> So from my perspective the downside of plugins is very small, and the >> upside is very large. > > I must admit I don't understand the upside. I've always thought of > plugins as something proprietary programs need because their source > isn't open. No. Many firefox plugins and linux kernel plugins (called modules) are opensource! Every GCC plugin has to be open source (because GCC is GPL) because it has to be GPL! > > In my view, plugins will bitrot quickly as GCC's interface changes; and > they won't even help with the learning curve - does anyone believe for a > second you won't have to understand compiler internals to write a plugin? Plugin will help to experiment, and a major point of a plugin is that it can be removed or disabled without impacting GCC major ability to compile stuff (it might only decrease performance, additional functionalities, .. if removed). Plugins should make daily work on GCC easier: you don't have to bootstrap everything! And you could release it (with its source code) even if it is incomplete, .... because it can be very easily disabled. And plugins could even be dynamically produced (shameless ad for my paper & work). The main point of a plugin is that it could be removed easily! Much harder for anything else. Just hacking GCC for making a feature which can be robustly disabled is a significant work! Plugins get you that for free... And it is essential for every kind of "experimental" or "additional" features! You really want it to be easy to remove! -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:27 ` Bernd Schmidt 2007-11-16 17:35 ` Richard Kenner 2007-11-16 17:46 ` Basile STARYNKEVITCH @ 2007-11-16 17:52 ` Joe Buck 2007-11-16 18:29 ` Diego Novillo 2007-11-17 11:39 ` Tom Tromey 4 siblings, 0 replies; 108+ messages in thread From: Joe Buck @ 2007-11-16 17:52 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Ian Lance Taylor, Richard Kenner, dnovillo, fleury, gcc On Fri, Nov 16, 2007 at 06:13:32PM +0100, Bernd Schmidt wrote: > I must admit I don't understand the upside. I've always thought of > plugins as something proprietary programs need because their source > isn't open. On the contrary, many successful free programs have plugins. Consider Emacs. The user can extend the editor using a Turing-complete extension language (elisp), and commands in the extension language have the same status as native commands in C. Consider Firefox. Again, there are vast numbers of useful extensions. They allow users to customize the tool in ways that the core developers wouldn't necessarily want to support. > In my view, plugins will bitrot quickly as GCC's interface changes; and > they won't even help with the learning curve - does anyone believe for a > second you won't have to understand compiler internals to write a plugin? A poorly-designed plugin architecture would rot quickly. A well-designed architecture would require maintainance, but not as much work to keep up (Firefox plugins often require changes to keep up with new versions). ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:27 ` Bernd Schmidt ` (2 preceding siblings ...) 2007-11-16 17:52 ` Joe Buck @ 2007-11-16 18:29 ` Diego Novillo 2007-11-17 11:39 ` Tom Tromey 4 siblings, 0 replies; 108+ messages in thread From: Diego Novillo @ 2007-11-16 18:29 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Ian Lance Taylor, Richard Kenner, Joe.Buck, fleury, gcc Bernd Schmidt wrote: > I must admit I don't understand the upside. I've always thought of > plugins as something proprietary programs need because their source > isn't open. On the contrary, the plug-in model is used in several large and complex open source projects (firefox, thunderbird, gimp, linux kernel, etc). It's precisely the complexity reduction features that make plug-ins so attractive. For us this means attracting more developers, which in turn means bigger potential for attracting long-time contributors, which helps with the long-term survival of GCC. > In my view, plugins will bitrot quickly as GCC's interface changes; and > they won't even help with the learning curve - does anyone believe for a > second you won't have to understand compiler internals to write a plugin? Of course not. But with a plug-in framework you get to interact with exactly the set of components important for your work, you don't have to deal with the whole compiler and its internal build machinery. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-16 17:27 ` Bernd Schmidt ` (3 preceding siblings ...) 2007-11-16 18:29 ` Diego Novillo @ 2007-11-17 11:39 ` Tom Tromey 2007-11-19 1:08 ` Brendon Costa 4 siblings, 1 reply; 108+ messages in thread From: Tom Tromey @ 2007-11-17 11:39 UTC (permalink / raw) To: Bernd Schmidt Cc: Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc >>>>> "Bernd" == Bernd Schmidt <bernds_cb1@t-online.de> writes: Bernd> I must admit I don't understand the upside. I've always thought of Bernd> plugins as something proprietary programs need because their source Bernd> isn't open. Everybody explained about the existing free software that has plugins. But, I thought I'd mention a few use cases for plugins. The biggest benefit of a plugin system is that you can add things to the compiler without requiring all your users to build their own compiler. E.g., Mozilla developers have said before (even earlier in this thread) that they would like to be able to run Mozilla-specific analysis passes over their code, say before checkin. Probably this consists of a bunch of warning checks that are suitable for Mozilla but not suitable for inclusion in GCC. With a plugin system they have the option of providing "Mozilla GCC plugin for Fedora 9", or whatever, and avoiding the mess of "to build Mozilla first you have to build GCC with patch X". Bernd> In my view, plugins will bitrot quickly as GCC's interface Bernd> changes; and they won't even help with the learning curve - Bernd> does anyone believe for a second you won't have to understand Bernd> compiler internals to write a plugin? Plugins are about deployment, not development. They don't make writing the code much simpler. That is why we can argue that the risk they pose is small: they don't make it significantly simpler to make a proprietary GCC. Tom ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-17 11:39 ` Tom Tromey @ 2007-11-19 1:08 ` Brendon Costa 0 siblings, 0 replies; 108+ messages in thread From: Brendon Costa @ 2007-11-19 1:08 UTC (permalink / raw) To: tromey Cc: Bernd Schmidt, Ian Lance Taylor, Richard Kenner, dnovillo, Joe.Buck, fleury, gcc Tom Tromey wrote: > Bernd> In my view, plugins will bitrot quickly as GCC's interface > Bernd> changes; and they won't even help with the learning curve - > Bernd> does anyone believe for a second you won't have to understand > Bernd> compiler internals to write a plugin? > > Plugins are about deployment, not development. They don't make > writing the code much simpler. That is why we can argue that the risk > they pose is small: they don't make it significantly simpler to make a > proprietary GCC. > In my situation this point is right on the mark. I follow with a concrete example. My project: "EDoc++", requires a patched version of GCC in order to perform static analysis of source code. I approached the debian maintainers list with a debian package for this project to see if they would include it in the official repositories. It was not accepted and the reason for that is because it includes another patched version of GCC which takes up too much disk space. They don't want to accept these sorts of projects because they all effectively require duplicates of the same code(GCC). This problem of deployment could be solved with plugins. Development for my project would not be overly different with the plugin framework included. I dont expect to be able to write plugins without an understanding of the internals of GCC which the plugin is being written for. What i expect from the framework is simplified, standard method of deployment for additional GCC "features". As an overall comment on the issues being discussed i think we should not deliberately omit features that will be useful to the open source community just to deny these same features to proprietary developers. This is just shooting ourselves in the foot in order to do the same to others. It makes no sense as we are restricting our own progress for a possible misuse of the feature by others (That is already occurring anyway). Brendon. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 21:53 ` Richard Kenner 2007-11-15 22:04 ` Ian Lance Taylor @ 2007-11-15 22:47 ` Diego Novillo 2007-11-15 23:05 ` Richard Kenner 1 sibling, 1 reply; 108+ messages in thread From: Diego Novillo @ 2007-11-15 22:47 UTC (permalink / raw) To: Richard Kenner; +Cc: Joe.Buck, fleury, gcc Richard Kenner wrote: > Therefore, I think it's important for us to make it as > technically hard as possible for people to do such a linkage by readin and > writing tree or communicating as different libraries or DLLs. I'm very > much against any sort of "plug in" precisely for this reason. That's the line of reasoning that I find weak. It is, in fact, extremely simple to integrate GCC into another compiler. All you need to do is insert a gimple or RTL converter somewhere in passes.c. Having plug-ins will not make this step any easier. If a third party is willing to violate the GPL, the presence of a plug-in infrastructure will _not_ make their job significantly easier. > That depends on the importance you attach to the philosophy of free > software. That's precisely the reason why I think it is imperative for us to keep improving GCC's internal architecture. If we offer a solid compiler framework for people to use, we will increase its attractiveness to universities and research institutions, which are the very pools where future compiler engineers will come from. That will help the long-term survival of the project. It is very easy for us to make code developed using plug-ins to be covered by the GPL. They will be using GCC header files, after all. Diego. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Progress on GCC plugins ? 2007-11-15 22:47 ` Diego Novillo @ 2007-11-15 23:05 ` Richard Kenner 0 siblings, 0 replies; 108+ messages in thread From: Richard Kenner @ 2007-11-15 23:05 UTC (permalink / raw) To: dnovillo; +Cc: Joe.Buck, fleury, gcc > If a third party is willing to violate the GPL, the presence of a > plug-in infrastructure will _not_ make their job significantly easier. The issue isn't the ease in which it violates the GPL, but the ease in which you can show it *is* a violation! If there's no plug-in and you link directly with GCC, there's no question that such code is covered by the GPL. If you use a plug-in, there *is* such a question and people might well believe it is *not* a GPL violation. > It is very easy for us to make code developed using plug-ins to be > covered by the GPL. They will be using GCC header files, after all. I don't want to turn this into a legal discussion, but there is some legal ambiguity about that statement too. ^ permalink raw reply [flat|nested] 108+ messages in thread
end of thread, other threads:[~2007-11-28 3:11 UTC | newest] Thread overview: 108+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-11-07 8:37 Progress on GCC plugins ? Emmanuel Fleury 2007-11-07 16:47 ` Joe Buck 2007-11-07 17:11 ` Basile STARYNKEVITCH 2007-11-07 17:20 ` Tom Tromey 2007-11-07 17:34 ` Robert Dewar 2007-11-07 17:47 ` Chris Lattner 2007-11-08 13:02 ` Florian Weimer 2007-11-08 14:01 ` Robert Dewar 2007-11-07 17:49 ` Dave Korn 2007-11-07 18:45 ` David Edelsohn 2007-11-07 19:11 ` Robert Dewar 2007-11-07 21:55 ` Brendon Costa 2007-11-07 22:32 ` Robert Dewar 2007-11-07 22:43 ` Brendon Costa 2007-11-07 22:57 ` Robert Dewar 2007-11-07 23:43 ` David Edelsohn 2007-11-08 0:00 ` Brendon Costa 2007-11-07 23:44 ` Brendon Costa 2007-11-25 0:02 ` Alexandre Oliva 2007-11-25 17:15 ` Richard Kenner 2007-11-08 12:57 ` Dave Korn 2007-11-08 0:10 ` Brendon Costa 2007-11-08 7:21 ` Ian Lance Taylor 2007-11-08 10:23 ` Emmanuel Fleury 2007-11-08 20:51 ` Mark Mitchell 2007-11-09 18:12 ` Gerald.Williams 2007-11-15 21:43 ` Diego Novillo 2007-11-15 21:46 ` Joe Buck 2007-11-15 21:53 ` Richard Kenner 2007-11-15 22:04 ` Ian Lance Taylor 2007-11-15 22:46 ` Richard Kenner 2007-11-15 22:49 ` Diego Novillo 2007-11-15 23:24 ` Richard Kenner 2007-11-15 23:37 ` Diego Novillo 2007-11-16 0:24 ` Richard Kenner 2007-11-16 1:24 ` Diego Novillo 2007-11-24 23:31 ` Alexandre Oliva 2007-11-24 23:33 ` Diego Novillo 2007-11-25 0:11 ` Alexandre Oliva 2007-11-16 1:39 ` Ian Lance Taylor 2007-11-16 15:49 ` Alexander Lamaison 2007-11-16 16:08 ` Martin Jambor 2007-11-16 16:12 ` Alexander Lamaison 2007-11-15 22:54 ` Benjamin Smedberg 2007-11-15 23:50 ` Ian Lance Taylor 2007-11-15 22:53 ` Andrew Haley 2007-11-15 22:55 ` Ian Lance Taylor 2007-11-16 13:33 ` Andrew Haley 2007-11-16 16:18 ` Ian Lance Taylor 2007-11-16 16:21 ` Andrew Haley 2007-11-16 16:53 ` Basile STARYNKEVITCH 2007-11-16 16:56 ` Ian Lance Taylor 2007-11-16 16:58 ` Diego Novillo 2007-11-16 17:08 ` Andrew Haley 2007-11-16 17:10 ` Diego Novillo 2007-11-16 18:17 ` Benjamin Smedberg 2007-11-23 0:25 ` Frank Ch. Eigler 2007-11-16 17:15 ` Basile STARYNKEVITCH 2007-11-24 23:22 ` Alexandre Oliva 2007-11-25 0:10 ` Chris Lattner 2007-11-16 17:16 ` David Edelsohn 2007-11-16 17:25 ` Dep, Khushil (GE Money) 2007-11-16 17:32 ` Tom Tromey 2007-11-17 14:15 ` Gabriel Dos Reis 2007-11-24 23:22 ` Alexandre Oliva 2007-11-24 23:29 ` Richard Kenner 2007-11-25 20:43 ` Tom Tromey 2007-11-26 6:24 ` Taras Glek 2007-11-26 19:49 ` Tom Tromey 2007-11-26 21:31 ` Basile STARYNKEVITCH 2007-11-27 0:14 ` Tom Tromey 2007-11-27 20:51 ` Alexandre Oliva 2007-11-28 7:53 ` Ian Lance Taylor 2007-11-16 17:18 ` Richard Kenner 2007-11-16 17:27 ` Joe Buck 2007-11-16 17:31 ` Basile STARYNKEVITCH 2007-11-16 17:38 ` Joe Buck 2007-11-16 19:21 ` Gerald.Williams 2007-11-16 19:58 ` Joe Buck 2007-11-16 21:43 ` Gerald.Williams 2007-11-16 18:54 ` Diego Novillo 2007-11-16 19:13 ` Martin Jambor 2007-11-18 22:12 ` Robert Dewar 2007-11-19 4:16 ` Gabriel Dos Reis 2007-11-19 4:23 ` Richard Kenner 2007-11-19 9:11 ` Robert Dewar 2007-11-19 9:49 ` Richard Kenner 2007-11-19 10:21 ` Robert Dewar 2007-11-19 12:14 ` Gabriel Dos Reis 2007-11-19 12:28 ` Gabriel Dos Reis 2007-11-19 13:18 ` Robert Dewar 2007-11-19 8:26 ` Robert Dewar 2007-11-19 8:37 ` Robert Dewar 2007-11-16 16:24 ` Basile STARYNKEVITCH 2007-11-16 17:03 ` Ian Lance Taylor 2007-11-16 19:09 ` Martin Michlmayr 2007-11-16 20:27 ` Ian Lance Taylor 2007-11-16 0:01 ` Emmanuel Fleury 2007-11-16 17:27 ` Bernd Schmidt 2007-11-16 17:35 ` Richard Kenner 2007-11-16 18:41 ` Dave Korn 2007-11-16 17:46 ` Basile STARYNKEVITCH 2007-11-16 17:52 ` Joe Buck 2007-11-16 18:29 ` Diego Novillo 2007-11-17 11:39 ` Tom Tromey 2007-11-19 1:08 ` Brendon Costa 2007-11-15 22:47 ` Diego Novillo 2007-11-15 23:05 ` Richard Kenner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).