* Merging Apple's Objective-C 2.0 compiler changes @ 2010-09-09 10:11 Nicola Pero 2010-09-09 10:32 ` Nicola Pero ` (3 more replies) 0 siblings, 4 replies; 90+ messages in thread From: Nicola Pero @ 2010-09-09 10:11 UTC (permalink / raw) To: gcc; +Cc: Mike Stump Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to GCC into FSF GCC trunk ? Any legal obstacles ? If we start producing patches to the current FSF GCC trunk that merge these modifications, would they be accepted ? I think Apple would benefit from merging of their modifications in that we'd merge the Apple/NeXT runtime support as well. :-) They don't have to do any work. Thanks ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 10:11 Merging Apple's Objective-C 2.0 compiler changes Nicola Pero @ 2010-09-09 10:32 ` Nicola Pero 2010-09-09 11:36 ` Richard Kenner 2010-09-09 11:02 ` Mike Stump ` (2 subsequent siblings) 3 siblings, 1 reply; 90+ messages in thread From: Nicola Pero @ 2010-09-09 10:32 UTC (permalink / raw) To: gcc, Mike Stump > Can we (legally) merge Apple's Objective-C / Objective-C++ > modifications to GCC into FSF GCC trunk ? > Any legal obstacles ? I assume Apple had signed a copyright assignment to the FSF for all changes to GCC, moreover I checked the modified GCC source code that Apple distributes and all the copyright notices on all files mention the "Free Software Foundation Inc." as the copyright holder. I guess that means the changes have already been assigned to the FSF and we're free to merge ? :-) Thanks ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 10:32 ` Nicola Pero @ 2010-09-09 11:36 ` Richard Kenner 0 siblings, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-09 11:36 UTC (permalink / raw) To: nicola.pero; +Cc: gcc, mikestump > I assume Apple had signed a copyright assignment to the FSF for all > changes to GCC, moreover I checked > the modified GCC source code that Apple distributes and all the > copyright notices on all files mention the > "Free Software Foundation Inc." as the copyright holder. > > I guess that means the changes have already been assigned to the FSF > and we're free to merge ? :-) The copyright notice on the files has no legal significance. You need to make sure that: (1) There is a copyright assignment on file. (2) You get the files from Apple directly in a way that makes it clear that the assignment applies to those files. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 10:11 Merging Apple's Objective-C 2.0 compiler changes Nicola Pero 2010-09-09 10:32 ` Nicola Pero @ 2010-09-09 11:02 ` Mike Stump 2010-09-09 19:05 ` Dave Korn 2010-09-09 17:09 ` Chris Lattner 2010-11-02 15:31 ` Ed Smith-Rowland 3 siblings, 1 reply; 90+ messages in thread From: Mike Stump @ 2010-09-09 11:02 UTC (permalink / raw) To: Nicola Pero; +Cc: gcc On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: > Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to GCC into FSF GCC trunk ? My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. Chris Lattner could provide an Apple answer, I'd recommend contacting him. > If we start producing patches to the current FSF GCC trunk that merge these modifications, would they be accepted ? Sure, after Apple or the FSF (or someone else around here) weighs in on the matter. I wouldn't expect it to be a problem, as Apple does have an assignment and Apple does own the work in question and Apple does distribute it to the general public under a GPL v 2 or later clause. Once someone else green lights that, I'd pre-approve the integration of gcc/objc/*. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 11:02 ` Mike Stump @ 2010-09-09 19:05 ` Dave Korn 2010-09-09 19:19 ` Jack Howarth 2010-09-09 21:09 ` Chris Lattner 0 siblings, 2 replies; 90+ messages in thread From: Dave Korn @ 2010-09-09 19:05 UTC (permalink / raw) To: Mike Stump; +Cc: Nicola Pero, gcc On 09/09/2010 12:01, Mike Stump wrote: > On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: >> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications >> to GCC into FSF GCC trunk ? > > My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. > Chris Lattner could provide an Apple answer, I'd recommend contacting him. We've just had a similar discussion on the binutils list about some changes in Atmel's AVR32 compilers, and the conclusion we arrived at was that this can't "just be done" by a third party, even in the presence of a blanket corporate assignment: >> If we start producing patches to the current FSF GCC trunk that merge >> these modifications, would they be accepted ? > > Sure, after Apple or the FSF (or someone else around here) weighs in on the > matter. I wouldn't expect it to be a problem, as Apple does have an > assignment and Apple does own the work in question and Apple does > distribute it to the general public under a GPL v 2 or later clause. But: the assignment only applies to patches that are *explicitly* submitted by the copyright holder to the FSF (via the -patches list or similar suitable mechanism) for inclusion in the upstream source base. (Anything they only use internally rather than distribute, for example, they don't have to submit or assign, and even anything they distribute publicly, they aren't obliged to send upstream, just to fulfill the source guarantee to downstream recipients.) *Until and unless* Apple itself submits the code to the FSF, Apple retains the copyright; which means that nobody else has the right to submit it to the FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment that allows them to sub-assign.... but that sounds even more complicated to me.) cheers, DaveK ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 19:05 ` Dave Korn @ 2010-09-09 19:19 ` Jack Howarth 2010-09-09 19:30 ` Dave Korn 2010-09-09 21:12 ` Chris Lattner 2010-09-09 21:09 ` Chris Lattner 1 sibling, 2 replies; 90+ messages in thread From: Jack Howarth @ 2010-09-09 19:19 UTC (permalink / raw) To: Dave Korn; +Cc: Mike Stump, Nicola Pero, gcc On Thu, Sep 09, 2010 at 08:27:16PM +0100, Dave Korn wrote: > On 09/09/2010 12:01, Mike Stump wrote: > > On Sep 9, 2010,@3:11 AM, Nicola Pero wrote: > >> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications > >> to GCC into FSF GCC trunk ? > > > > My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. > > Chris Lattner could provide an Apple answer, I'd recommend contacting him. > > We've just had a similar discussion on the binutils list about some changes > in Atmel's AVR32 compilers, and the conclusion we arrived@was that this > can't "just be done" by a third party, even in the presence of a blanket > corporate assignment: > > >> If we start producing patches to the current FSF GCC trunk that merge > >> these modifications, would they be accepted ? > > > > Sure, after Apple or the FSF (or someone else around here) weighs in on the > > matter. I wouldn't expect it to be a problem, as Apple does have an > > assignment and Apple does own the work in question and Apple does > > distribute it to the general public under a GPL v 2 or later clause. > > But: the assignment only applies to patches that are *explicitly* submitted > by the copyright holder to the FSF (via the -patches list or similar suitable > mechanism) for inclusion in the upstream source base. (Anything they only use > internally rather than distribute, for example, they don't have to submit or > assign, and even anything they distribute publicly, they aren't obliged to > send upstream, just to fulfill the source guarantee to downstream recipients.) > > *Until and unless* Apple itself submits the code to the FSF, Apple retains > the copyright; which means that nobody else has the right to submit it to the > FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment > that allows them to sub-assign.... but that sounds even more complicated to me.) > > cheers, > DaveK Perhaps a rational approach would be to contact whoever at Apple currently is charged with maintaining their objc languages about the issue. If the issue is framed in terms of insuring that their definition of the Objective C language has availability outside of their own platforms, the issue might have more traction. The major question is what happens to their own internal branches? Hopefully FSF tolerates the idea that their own internal GPLv2 branches retain their same status and that only FSF trees with the contributed code exist under GPL v3. That is the code effectively forks again at the contribution revision point (just as if the relicensing of gcc at 4.2.1 had happened at a later date). Jack ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 19:19 ` Jack Howarth @ 2010-09-09 19:30 ` Dave Korn 2010-09-09 21:12 ` Chris Lattner 1 sibling, 0 replies; 90+ messages in thread From: Dave Korn @ 2010-09-09 19:30 UTC (permalink / raw) To: Jack Howarth; +Cc: Mike Stump, Nicola Pero, gcc On 09/09/2010 20:19, Jack Howarth wrote: >> On 09/09/2010 12:01, Mike Stump wrote: >>> Chris Lattner could provide an Apple answer, I'd recommend contacting him. > Perhaps a rational approach would be to contact whoever at Apple currently is > charged with maintaining their objc languages about the issue. Yep, Mike suggested it, and I was just enlarging on why it is really the only valid way to get the changes into trunk. cheers, DaveK ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 19:19 ` Jack Howarth 2010-09-09 19:30 ` Dave Korn @ 2010-09-09 21:12 ` Chris Lattner 2010-09-10 0:18 ` Joe Buck 1 sibling, 1 reply; 90+ messages in thread From: Chris Lattner @ 2010-09-09 21:12 UTC (permalink / raw) To: Jack Howarth; +Cc: Dave Korn, Mike Stump, Nicola Pero, gcc On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote: > Perhaps a rational approach would be to contact whoever at Apple currently is > charged with maintaining their objc languages about the issue. Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 21:12 ` Chris Lattner @ 2010-09-10 0:18 ` Joe Buck 2010-09-10 9:13 ` Richard Guenther 0 siblings, 1 reply; 90+ messages in thread From: Joe Buck @ 2010-09-10 0:18 UTC (permalink / raw) To: Chris Lattner; +Cc: Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On Thu, Sep 09, 2010 at 02:11:43PM -0700, Chris Lattner wrote: > On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote: > > Perhaps a rational approach would be to contact whoever at Apple currently is > > charged with maintaining their objc languages about the issue. > > Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF. To clarify, anything not checked in on gcc.gnu.org somewhere must be assumed to be copyright Apple, not copyright FSF, and has not been contributed, and Apple has no plans to contribute more code. However, anything on gcc.gnu.org has been contributed. I understand that the main issue is that Apple objects to GPLv3, but the exact reason doesn't necessarily matter that much. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 0:18 ` Joe Buck @ 2010-09-10 9:13 ` Richard Guenther 2010-09-10 9:38 ` Steven Bosscher 2010-09-10 11:50 ` Richard Kenner 0 siblings, 2 replies; 90+ messages in thread From: Richard Guenther @ 2010-09-10 9:13 UTC (permalink / raw) To: Joe Buck Cc: Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On Fri, Sep 10, 2010 at 1:15 AM, Joe Buck <Joe.Buck@synopsys.com> wrote: > On Thu, Sep 09, 2010 at 02:11:43PM -0700, Chris Lattner wrote: >> On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote: >> > Perhaps a rational approach would be to contact whoever at Apple currently is >> > charged with maintaining their objc languages about the issue. >> >> Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF. > > To clarify, anything not checked in on gcc.gnu.org somewhere must be > assumed to be copyright Apple, not copyright FSF, and has not been > contributed, and Apple has no plans to contribute more code. However, > anything on gcc.gnu.org has been contributed. > > I understand that the main issue is that Apple objects to GPLv3, but > the exact reason doesn't necessarily matter that much. Btw, we do seem to have code in GCC that is not copyrighted by the FSF. For example I don't think the FSF owns copyright on the ACATS testsuite, and libffi mentions (c) by RedHat. For GCC as a project it should matter that the code is distributable under GPLv3 which I think Apples changes are. Copyright assignment to the FSF might be convenient, but isn't legally necessary (only necessary by policy and even that seems to have existing exceptions). Thus, if getting the copyright assigned to the FSF for the ObjC changes proves to be impossible I'd suggest to ask the SC for a policy exception. Richard. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:13 ` Richard Guenther @ 2010-09-10 9:38 ` Steven Bosscher 2010-09-10 9:42 ` Richard Guenther ` (2 more replies) 2010-09-10 11:50 ` Richard Kenner 1 sibling, 3 replies; 90+ messages in thread From: Steven Bosscher @ 2010-09-10 9:38 UTC (permalink / raw) To: Richard Guenther Cc: Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On Fri, Sep 10, 2010 at 11:13 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > Btw, we do seem to have code in GCC that is not copyrighted by the FSF. > For example I don't think the FSF owns copyright on the ACATS > testsuite, and libffi mentions (c) by RedHat. That code is not part of the compiler proper. The policy has always been different for the test suites and for runtime libraries. > Thus, if getting the copyright assigned to the FSF for the ObjC changes > proves to be impossible I'd suggest to ask the SC for a policy > exception. IMHO the risk of "leakage" of such code to places outside the ObjC front end would be too big. To be completely honest: I think Nicola's efforts are laudable but I wonder whether it helps GCC-the-project more than it hurts. GNU ObjC has so few users that it seems hardly worth the effort to upgrade the GNU ObjC front end to ObjC 2.0. And there are other issues: * What standard is going to be implemented? ObjC 2.0 is not even a documented language standard, so you probably end up with something that is incompatible with Apple ObjC anyway. Without a documented standard, the only "standard" is the Apple compiler, which you cannot look at without risking copyright problems. The latest state of ObjC 2.0 on apple branches on gcc.gnu.org may not be the "current" ObjC 2.0. * How do ObjC 2.0 and ObjC++ interact? Even now, there is already the problem of the two exception handling models, and AFAIU that will only get more complicated with ObjC 2.0. * What does it mean for existing GNU ObjC users to make the headers and runtime compatible with NEXTnow? These changes break source compatibility, I guess, and if that is indeed the case then the question is whether that is acceptable or not. Not that I want to discourage anyone. Just practical considerations... ;-) I can't believe I'm saing this but: It may be better to spend some effort on making clang work as a GCC front end. Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:38 ` Steven Bosscher @ 2010-09-10 9:42 ` Richard Guenther 2010-09-10 12:20 ` Manuel López-Ibáñez ` (2 more replies) 2010-09-10 10:56 ` Nicola Pero 2010-09-10 11:47 ` Joseph S. Myers 2 siblings, 3 replies; 90+ messages in thread From: Richard Guenther @ 2010-09-10 9:42 UTC (permalink / raw) To: Steven Bosscher Cc: Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > Not that I want to discourage anyone. Just practical considerations... > ;-) I can't believe I'm saing this but: It may be better to spend > some effort on making clang work as a GCC front end. Oh, indeed - I'd welcome patches making "frontend plugins" possible and plugging clang. Richard. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:42 ` Richard Guenther @ 2010-09-10 12:20 ` Manuel López-Ibáñez 2010-09-10 12:21 ` Richard Kenner 2010-09-10 12:38 ` Richard Guenther 2010-09-10 13:37 ` Paulo J. Matos 2010-09-10 17:31 ` Mike Stump 2 siblings, 2 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 12:20 UTC (permalink / raw) To: Richard Guenther Cc: Steven Bosscher, Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On 10 September 2010 11:42, Richard Guenther <richard.guenther@gmail.com> wrote: > On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > >> Not that I want to discourage anyone. Just practical considerations... >> ;-) I can't believe I'm saing this but: It may be better to spend >> some effort on making clang work as a GCC front end. > > Oh, indeed - I'd welcome patches making "frontend plugins" possible > and plugging clang. I wonder what would actually be needed to implement this? Since clang keeps around more information than GCC's FEs. New plugin hooks? I don't think you need FE plugins but a LLVM->GIMPLE converter plug to the gimplifier. Is adding code to GCC to handle LLVM intermediate language acceptable? Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 12:20 ` Manuel López-Ibáñez @ 2010-09-10 12:21 ` Richard Kenner 2010-09-10 12:28 ` Manuel López-Ibáñez 2010-09-10 12:38 ` Richard Guenther 1 sibling, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-10 12:21 UTC (permalink / raw) To: lopezibanez Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther, stevenb.gcc > > Oh, indeed - I'd welcome patches making "frontend plugins" possible > > and plugging clang. > > I wonder what would actually be needed to implement this? Some strong way of addressing the concern that this could be used to make proprietary front-ends or proprietary back-ends using part of GCC! ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 12:21 ` Richard Kenner @ 2010-09-10 12:28 ` Manuel López-Ibáñez 2010-09-10 13:00 ` Richard Kenner 0 siblings, 1 reply; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 12:28 UTC (permalink / raw) To: Richard Kenner Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther, stevenb.gcc On 10 September 2010 14:22, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: >> > Oh, indeed - I'd welcome patches making "frontend plugins" possible >> > and plugging clang. >> >> I wonder what would actually be needed to implement this? > > Some strong way of addressing the concern that this could be used to make > proprietary front-ends or proprietary back-ends using part of GCC! Why is this case different from the existing llvm-gcc? Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 12:28 ` Manuel López-Ibáñez @ 2010-09-10 13:00 ` Richard Kenner 2010-09-10 13:09 ` Steven Bosscher ` (2 more replies) 0 siblings, 3 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 13:00 UTC (permalink / raw) To: lopezibanez Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther, stevenb.gcc > > Some strong way of addressing the concern that this could be used to make > > proprietary front-ends or proprietary back-ends using part of GCC! > > Why is this case different from the existing llvm-gcc? It's the question of what one means by "plug-in interface". If you view it as no different from the existing llvm-gcc, then you're basically saying we already HAVE a plug-in interface. So then what are we talking about? So the answer to your question is "whatever the difference is between what we have now and what a plug-in interface would provide". :-) More seriously, the issue is copyright law. In order to write a front-end for GCC right now (or for a GCC front end to use another backend), you have to use a sufficient number of header files and interfaces of GCC that there's no question that it's a derived work from GCC and hence must have a compatible license. But if you create a well-defined interface, you have the legal issue that the better you do in isolating the two pieces, the weaker the case is that one piece is a derived work of the other and if it's not, then you indeed CAN have a proprietary front-end. This is an issue that goes back decades and influences a lot of GCC. For example, it might have been tempting to have the dump files (originally just RTL, but now tree) contain everything needed to read them back in and continue the compilation. But if this were done, then it would be trivial to have proprietary front ends, back ends, and optimizers. So RMS never allowed any such thing nor any scheme that resulted in having any file that could be used for such a purpose. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:00 ` Richard Kenner @ 2010-09-10 13:09 ` Steven Bosscher 2010-09-10 13:13 ` Manuel López-Ibáñez 2010-09-10 13:12 ` Manuel López-Ibáñez 2010-09-10 16:58 ` Mike Stump 2 siblings, 1 reply; 90+ messages in thread From: Steven Bosscher @ 2010-09-10 13:09 UTC (permalink / raw) To: Richard Kenner Cc: lopezibanez, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: >> > Some strong way of addressing the concern that this could be used to make >> > proprietary front-ends or proprietary back-ends using part of GCC! >> >> Why is this case different from the existing llvm-gcc? > > It's the question of what one means by "plug-in interface". If you > view it as no different from the existing llvm-gcc, then you're > basically saying we already HAVE a plug-in interface. So then what are > we talking about? Obviously not about the same thing. llvm-gcc is GCC front ends with LLVM as a back end. The idea here is clang with GCC as a back end. And all the concerns you raise are already addressed by the plugin exception. You're describing a situation that is already not allowed. Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:09 ` Steven Bosscher @ 2010-09-10 13:13 ` Manuel López-Ibáñez 2010-09-10 13:16 ` Manuel López-Ibáñez 2010-09-13 14:55 ` Paolo Bonzini 0 siblings, 2 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 13:13 UTC (permalink / raw) To: Steven Bosscher Cc: Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On 10 September 2010 15:00, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner > <kenner@vlsi1.ultra.nyu.edu> wrote: >>> > Some strong way of addressing the concern that this could be used to make >>> > proprietary front-ends or proprietary back-ends using part of GCC! >>> >>> Why is this case different from the existing llvm-gcc? >> >> It's the question of what one means by "plug-in interface". If you >> view it as no different from the existing llvm-gcc, then you're >> basically saying we already HAVE a plug-in interface. So then what are >> we talking about? > > Obviously not about the same thing. > > llvm-gcc is GCC front ends with LLVM as a back end. > > The idea here is clang with GCC as a back end. They are equivalent in the sense that I would understand why GCC would allow the former but it would fight against the latter. Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:13 ` Manuel López-Ibáñez @ 2010-09-10 13:16 ` Manuel López-Ibáñez 2010-09-13 14:55 ` Paolo Bonzini 1 sibling, 0 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 13:16 UTC (permalink / raw) To: Steven Bosscher Cc: Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On 10 September 2010 15:12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 10 September 2010 15:00, Steven Bosscher <stevenb.gcc@gmail.com> wrote: >> On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner >> <kenner@vlsi1.ultra.nyu.edu> wrote: >>>> > Some strong way of addressing the concern that this could be used to make >>>> > proprietary front-ends or proprietary back-ends using part of GCC! >>>> >>>> Why is this case different from the existing llvm-gcc? >>> >>> It's the question of what one means by "plug-in interface". If you >>> view it as no different from the existing llvm-gcc, then you're >>> basically saying we already HAVE a plug-in interface. So then what are >>> we talking about? >> >> Obviously not about the same thing. >> >> llvm-gcc is GCC front ends with LLVM as a back end. >> >> The idea here is clang with GCC as a back end. > > They are equivalent in the sense that I would understand why GCC would > allow the former but it would fight against the latter. s/would/wouldn't/ Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:13 ` Manuel López-Ibáñez 2010-09-10 13:16 ` Manuel López-Ibáñez @ 2010-09-13 14:55 ` Paolo Bonzini 2010-09-13 15:22 ` Paolo Bonzini 2010-09-13 15:55 ` Manuel López-Ibáñez 1 sibling, 2 replies; 90+ messages in thread From: Paolo Bonzini @ 2010-09-13 14:55 UTC (permalink / raw) To: gcc Cc: Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote: > On 10 September 2010 15:00, Steven Bosscher<stevenb.gcc@gmail.com> wrote: >> On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner >> <kenner@vlsi1.ultra.nyu.edu> wrote: >>>>> Some strong way of addressing the concern that this could be used to make >>>>> proprietary front-ends or proprietary back-ends using part of GCC! >>>> >>>> Why is this case different from the existing llvm-gcc? >>> >>> It's the question of what one means by "plug-in interface". If you >>> view it as no different from the existing llvm-gcc, then you're >>> basically saying we already HAVE a plug-in interface. So then what are >>> we talking about? >> >> Obviously not about the same thing. >> >> llvm-gcc is GCC front ends with LLVM as a back end. >> >> The idea here is clang with GCC as a back end. > > They are equivalent in the sense that I would understand why GCC would > allow the former but it would fight against the latter. Hmm, my impression was that GCC can mostly gain from clang-gcc, and only lose from llvm-gcc... Paolo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 14:55 ` Paolo Bonzini @ 2010-09-13 15:22 ` Paolo Bonzini 2010-09-13 15:55 ` Manuel López-Ibáñez 1 sibling, 0 replies; 90+ messages in thread From: Paolo Bonzini @ 2010-09-13 15:22 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote: > On 10 September 2010 15:00, Steven Bosscher<stevenb.gcc@gmail.com> wrote: >> On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner >> <kenner@vlsi1.ultra.nyu.edu> wrote: >>>>> Some strong way of addressing the concern that this could be used to make >>>>> proprietary front-ends or proprietary back-ends using part of GCC! >>>> >>>> Why is this case different from the existing llvm-gcc? >>> >>> It's the question of what one means by "plug-in interface". If you >>> view it as no different from the existing llvm-gcc, then you're >>> basically saying we already HAVE a plug-in interface. So then what are >>> we talking about? >> >> Obviously not about the same thing. >> >> llvm-gcc is GCC front ends with LLVM as a back end. >> >> The idea here is clang with GCC as a back end. > > They are equivalent in the sense that I would understand why GCC would > allow the former but it would fight against the latter. Hmm, my impression was that GCC can mostly gain from clang-gcc, and only lose from llvm-gcc... Paolo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 14:55 ` Paolo Bonzini 2010-09-13 15:22 ` Paolo Bonzini @ 2010-09-13 15:55 ` Manuel López-Ibáñez 2010-09-13 21:48 ` Jack Howarth 1 sibling, 1 reply; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-13 15:55 UTC (permalink / raw) To: Paolo Bonzini Cc: Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther On 13 September 2010 12:30, Paolo Bonzini <bonzini@gnu.org> wrote: > On 09/10/2010 03:12 PM, Manuel López-Ibáńez wrote: >> >> On 10 September 2010 15:00, Steven Bosscher<stevenb.gcc@gmail.com> wrote: >>> >>> On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner >>> <kenner@vlsi1.ultra.nyu.edu> wrote: >>>>>> >>>>>> Some strong way of addressing the concern that this could be used to >>>>>> make >>>>>> proprietary front-ends or proprietary back-ends using part of GCC! >>>>> >>>>> Why is this case different from the existing llvm-gcc? >>>> >>>> It's the question of what one means by "plug-in interface". If you >>>> view it as no different from the existing llvm-gcc, then you're >>>> basically saying we already HAVE a plug-in interface. So then what are >>>> we talking about? >>> >>> Obviously not about the same thing. >>> >>> llvm-gcc is GCC front ends with LLVM as a back end. >>> >>> The idea here is clang with GCC as a back end. >> >> They are equivalent in the sense that I wouldn't understand why GCC would >> allow the former but it would fight against the latter. > > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only > lose from llvm-gcc... What will be gained and what will be lost in your opinion? Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 15:55 ` Manuel López-Ibáñez @ 2010-09-13 21:48 ` Jack Howarth 2010-09-13 22:06 ` Manuel López-Ibáñez 0 siblings, 1 reply; 90+ messages in thread From: Jack Howarth @ 2010-09-13 21:48 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote: > On 13 September 2010 12:30, Paolo Bonzini <bonzini@gnu.org> wrote: > > > > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only > > lose from llvm-gcc... > > What will be gained and what will be lost in your opinion? > I assume that, by clang-gcc, Paolo meant adding plug-in support for a clang FE. It is unclear what is meant by llvm-gcc unless he really mean dragon-egg. Certainly llvm-gcc itself is a rather dead-end as there appears to be little appetite to attempt to update llvm-gcc to gcc 4.5 or later due to GPLv3. Perhaps the best approach would be to welcome both. While it can be clearly argued that dragon-egg is only a net gain for llvm, the reverse could be said for a clang FE plugin to FSF gcc. By supporting both approaches, both projects end up sharing and obtaining a net win for each. Jack > Cheers, > > Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 21:48 ` Jack Howarth @ 2010-09-13 22:06 ` Manuel López-Ibáñez 2010-09-13 22:27 ` Ian Lance Taylor 0 siblings, 1 reply; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-13 22:06 UTC (permalink / raw) To: Jack Howarth Cc: Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On 13 September 2010 16:55, Jack Howarth <howarth@bromo.med.uc.edu> wrote: > On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote: >> On 13 September 2010 12:30, Paolo Bonzini <bonzini@gnu.org> wrote: >> > >> > Hmm, my impression was that GCC can mostly gain from clang-gcc, and only >> > lose from llvm-gcc... >> >> What will be gained and what will be lost in your opinion? >> > > I assume that, by clang-gcc, Paolo meant adding plug-in support for > a clang FE. It is unclear what is meant by llvm-gcc unless he really mean > dragon-egg. Certainly llvm-gcc itself is a rather dead-end as there appears > to be little appetite to attempt to update llvm-gcc to gcc 4.5 or later > due to GPLv3. Perhaps the best approach would be to welcome both. While > it can be clearly argued that dragon-egg is only a net gain for llvm, > the reverse could be said for a clang FE plugin to FSF gcc. By supporting > both approaches, both projects end up sharing and obtaining a net win for > each. From a user-perspective, there are benefits on both clang->gcc and gcc->llvm. However, from what I know about the GCC project, I don't see yet how GCC developers can consider either more beneficial than the other. But I would be very interested on clarifying this issue, so anyone thinking about making clang->gcc possible can assess whether it is worth it. It seems Richard is supporting it, and that is a big vote in favour. I can guess why he is not similarly favourable to gcc->llvm, but then, others in the GCC project may be more favourable to gcc->llvm than to clang->gcc (depending what you are working on). So the question remains, would GCC accept patches to implement plugging clang to GCC? Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 22:06 ` Manuel López-Ibáñez @ 2010-09-13 22:27 ` Ian Lance Taylor 2010-09-13 22:33 ` Marcus Daniels 2010-09-14 8:30 ` Manuel López-Ibáñez 0 siblings, 2 replies; 90+ messages in thread From: Ian Lance Taylor @ 2010-09-13 22:27 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Jack Howarth, Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > From a user-perspective, there are benefits on both clang->gcc and > gcc->llvm. However, from what I know about the GCC project, I don't > see yet how GCC developers can consider either more beneficial than > the other. It seems to me that at the present moment LLVM's frontends are better than GCC's, and GCC's backends are better than LLVM's. By this I mean specifically that LLVM's frontends generate better diagnostics, whereas GCC's backends generate code that has better runtime performance. (LLVM also appears to run faster, which is a good feature but not in my mind a determining one.) Therefore, I see a clear benefit to clang->gcc, but I do not see a clear benefit to gcc->llvm. This comment is of course entirely independent of the licensing issues. Ian ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 22:27 ` Ian Lance Taylor @ 2010-09-13 22:33 ` Marcus Daniels 2010-09-14 8:30 ` Manuel López-Ibáñez 1 sibling, 0 replies; 90+ messages in thread From: Marcus Daniels @ 2010-09-13 22:33 UTC (permalink / raw) To: gcc On 9/13/10 2:04 PM, Ian Lance Taylor wrote: > Therefore, I see a clear benefit to clang->gcc, but I > do not see a clear benefit to gcc->llvm. Suppose you have large Fortran applications, and want to accelerate parts of them on graphics processors. Several of the OpenCL implementations use LLVM for runtime code generation, so one could compile the application to LTO, and let it go through some expensive stages of the GCC optimizer, and have LLVM bitcode staged for final translation to the GPU ISA. In general, make the distinction between heavy ahead-of-time compilation and light just-in-time compilation along the lines of GCC and LLVM. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-13 22:27 ` Ian Lance Taylor 2010-09-13 22:33 ` Marcus Daniels @ 2010-09-14 8:30 ` Manuel López-Ibáñez 2010-09-14 9:08 ` Ian Lance Taylor 2010-09-14 10:09 ` Steven Bosscher 1 sibling, 2 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-14 8:30 UTC (permalink / raw) To: Ian Lance Taylor Cc: Jack Howarth, Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On 13 September 2010 22:04, Ian Lance Taylor <iant@google.com> wrote: > Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > >> From a user-perspective, there are benefits on both clang->gcc and >> gcc->llvm. However, from what I know about the GCC project, I don't >> see yet how GCC developers can consider either more beneficial than >> the other. > > It seems to me that at the present moment LLVM's frontends are better > than GCC's, and GCC's backends are better than LLVM's. By this I mean > specifically that LLVM's frontends generate better diagnostics, whereas > GCC's backends generate code that has better runtime performance. (LLVM > also appears to run faster, which is a good feature but not in my mind a > determining one.) Therefore, I see a clear benefit to clang->gcc, but I > do not see a clear benefit to gcc->llvm. This comment is of course > entirely independent of the licensing issues. I think you are again talking about user benefits. You don't see a (user) benefit in gcc->llvm because you perhaps do not use the features that LLVM has and GCC doesn't. But users of gcc->llvm surely see a large benefit if people have spent so much effort working on it, first as a patched gcc and now as a plugin. But I am talking about benefits to GCC. Do you see any benefit/downside on adding code to GCC to enable a plugin that implements clang->gcc? Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 8:30 ` Manuel López-Ibáñez @ 2010-09-14 9:08 ` Ian Lance Taylor 2010-09-14 10:13 ` Manuel López-Ibáñez 2010-09-14 10:09 ` Steven Bosscher 1 sibling, 1 reply; 90+ messages in thread From: Ian Lance Taylor @ 2010-09-14 9:08 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Jack Howarth, Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > On 13 September 2010 22:04, Ian Lance Taylor <iant@google.com> wrote: >> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: >> >>> From a user-perspective, there are benefits on both clang->gcc and >>> gcc->llvm. However, from what I know about the GCC project, I don't >>> see yet how GCC developers can consider either more beneficial than >>> the other. >> >> It seems to me that at the present moment LLVM's frontends are better >> than GCC's, and GCC's backends are better than LLVM's. By this I mean >> specifically that LLVM's frontends generate better diagnostics, whereas >> GCC's backends generate code that has better runtime performance. (LLVM >> also appears to run faster, which is a good feature but not in my mind a >> determining one.) Therefore, I see a clear benefit to clang->gcc, but I >> do not see a clear benefit to gcc->llvm. This comment is of course >> entirely independent of the licensing issues. > > I think you are again talking about user benefits. I'm not sure I understand the distinction you are drawing. What is the difference between a benefit to users of gcc and a benefit to gcc itself? > You don't see a > (user) benefit in gcc->llvm because you perhaps do not use the > features that LLVM has and GCC doesn't. But users of gcc->llvm surely > see a large benefit if people have spent so much effort working on it, > first as a patched gcc and now as a plugin. I understand the benefit that existed before clang. And my general understanding is that clang C++ support is not yet complete, so there is a benefit there, but only a temporary one. I don't see a real benefit going forward. > But I am talking about benefits to GCC. Do you see any > benefit/downside on adding code to GCC to enable a plugin that > implements clang->gcc? Since for me benefits to users of gcc are pretty much the same as benefits to gcc, yes, I see a benefit. Ian ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 9:08 ` Ian Lance Taylor @ 2010-09-14 10:13 ` Manuel López-Ibáñez 2010-09-14 11:14 ` Steven Bosscher 2010-09-14 12:05 ` Ian Lance Taylor 0 siblings, 2 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-14 10:13 UTC (permalink / raw) To: Ian Lance Taylor Cc: Jack Howarth, Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On 13 September 2010 23:41, Ian Lance Taylor <iant@google.com> wrote: > Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > >> On 13 September 2010 22:04, Ian Lance Taylor <iant@google.com> wrote: >>> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: >>> >>>> From a user-perspective, there are benefits on both clang->gcc and >>>> gcc->llvm. However, from what I know about the GCC project, I don't >>>> see yet how GCC developers can consider either more beneficial than >>>> the other. >>> >>> It seems to me that at the present moment LLVM's frontends are better >>> than GCC's, and GCC's backends are better than LLVM's. By this I mean >>> specifically that LLVM's frontends generate better diagnostics, whereas >>> GCC's backends generate code that has better runtime performance. (LLVM >>> also appears to run faster, which is a good feature but not in my mind a >>> determining one.) Therefore, I see a clear benefit to clang->gcc, but I >>> do not see a clear benefit to gcc->llvm. This comment is of course >>> entirely independent of the licensing issues. >> >> I think you are again talking about user benefits. > > I'm not sure I understand the distinction you are drawing. What is the > difference between a benefit to users of gcc and a benefit to gcc > itself? > >> You don't see a >> (user) benefit in gcc->llvm because you perhaps do not use the >> features that LLVM has and GCC doesn't. But users of gcc->llvm surely >> see a large benefit if people have spent so much effort working on it, >> first as a patched gcc and now as a plugin. > > I understand the benefit that existed before clang. And my general > understanding is that clang C++ support is not yet complete, so there is > a benefit there, but only a temporary one. I don't see a real benefit > going forward. Access to all the other GCC front-ends that the LLVM project has not (yet) reimplemented? Someone provided above a real user-case for gcc->llvm involving Fortran. I don't think dragon-egg development is stalled at all. >> But I am talking about benefits to GCC. Do you see any >> benefit/downside on adding code to GCC to enable a plugin that >> implements clang->gcc? > > Since for me benefits to users of gcc are pretty much the same as > benefits to gcc, yes, I see a benefit. By that rule, it is clearly beneficial for some gcc users to compile Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg is beneficial to GCC. Anyway, I don't see anyone implementing clang->gcc soon, but it is good to know it would be welcome. Thanks for answering, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 10:13 ` Manuel López-Ibáñez @ 2010-09-14 11:14 ` Steven Bosscher 2010-09-14 12:40 ` Manuel López-Ibáñez 2010-09-14 12:05 ` Ian Lance Taylor 1 sibling, 1 reply; 90+ messages in thread From: Steven Bosscher @ 2010-09-14 11:14 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Ian Lance Taylor, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: >> I understand the benefit that existed before clang. And my general >> understanding is that clang C++ support is not yet complete, so there is >> a benefit there, but only a temporary one. I don't see a real benefit >> going forward. > > Access to all the other GCC front-ends that the LLVM project has not > (yet) reimplemented? Someone provided above a real user-case for > gcc->llvm involving Fortran. I don't think dragon-egg development is > stalled at all. And some (including yours truly) consider this little more than theft. Especially since there is GCC-bashing on the one side, and taking the bits they like on the other. >> Since for me benefits to users of gcc are pretty much the same as >> benefits to gcc, yes, I see a benefit. > > By that rule, it is clearly beneficial for some gcc users to compile > Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg > is beneficial to GCC. No it "is" not, you "think it is", i.e. opinion. Again, I don't share that opinion at all, because this means there is less motivation for developers to add OpenCL to GCC itself. Anyway, we're waaaaaaaaaaay off-topic here from the original question about improving ObjC in GCC. Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 11:14 ` Steven Bosscher @ 2010-09-14 12:40 ` Manuel López-Ibáñez 2010-09-14 13:18 ` Ian Lance Taylor 2010-09-14 13:37 ` Steven Bosscher 0 siblings, 2 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-14 12:40 UTC (permalink / raw) To: Steven Bosscher Cc: Ian Lance Taylor, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On 14 September 2010 00:16, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez > <lopezibanez@gmail.com> wrote: >>> I understand the benefit that existed before clang. And my general >>> understanding is that clang C++ support is not yet complete, so there is >>> a benefit there, but only a temporary one. I don't see a real benefit >>> going forward. >> >> Access to all the other GCC front-ends that the LLVM project has not >> (yet) reimplemented? Someone provided above a real user-case for >> gcc->llvm involving Fortran. I don't think dragon-egg development is >> stalled at all. > > And some (including yours truly) consider this little more than theft. > Especially since there is GCC-bashing on the one side, and taking the > bits they like on the other. > > >>> Since for me benefits to users of gcc are pretty much the same as >>> benefits to gcc, yes, I see a benefit. >> >> By that rule, it is clearly beneficial for some gcc users to compile >> Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg >> is beneficial to GCC. > > No it "is" not, you "think it is", i.e. opinion. Again, I don't share > that opinion at all, because this means there is less motivation for > developers to add OpenCL to GCC itself. In the same sense that adding clang->gcc means that there is less motivation for developers to improve the current C/C++ FEs. So I guess you are against this as well. But then, just a few mails above, you are the one who proposed adding clang to gcc in the first place. Sorry, it seems a contradiction to me and I cannot get my head around it. > Anyway, we're waaaaaaaaaaay off-topic here from the original question > about improving ObjC in GCC. Well, the discussion is whether it makes sense to replace the ObjC FE with clang directly. I would say you disagree, but then you proposed it. I am ambivalent since my understanding is that replacing parts of GCC is bad. But then Richard and Ian surprised me by being in favour because it would benefit gcc users. I am just trying to make sense of it. Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 12:40 ` Manuel López-Ibáñez @ 2010-09-14 13:18 ` Ian Lance Taylor 2010-09-14 14:14 ` Richard Guenther 2010-09-14 15:19 ` David Edelsohn 2010-09-14 13:37 ` Steven Bosscher 1 sibling, 2 replies; 90+ messages in thread From: Ian Lance Taylor @ 2010-09-14 13:18 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > In the same sense that adding clang->gcc means that there is less > motivation for developers to improve the current C/C++ FEs. From the perspective of gcc, I think the goal of clang->gcc would be to replace the current frontends entirely. Ian ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 13:18 ` Ian Lance Taylor @ 2010-09-14 14:14 ` Richard Guenther 2010-09-15 7:23 ` Diego Novillo 2010-09-14 15:19 ` David Edelsohn 1 sibling, 1 reply; 90+ messages in thread From: Richard Guenther @ 2010-09-14 14:14 UTC (permalink / raw) To: Ian Lance Taylor Cc: Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor <iant@google.com> wrote: > Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > >> In the same sense that adding clang->gcc means that there is less >> motivation for developers to improve the current C/C++ FEs. > > From the perspective of gcc, I think the goal of clang->gcc would be to > replace the current frontends entirely. Yes, doing clang->gcc would get us the C family frontends disentanglement from the middle-end "for free". Richard. > Ian > ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 14:14 ` Richard Guenther @ 2010-09-15 7:23 ` Diego Novillo 2010-09-15 8:34 ` Joseph S. Myers 0 siblings, 1 reply; 90+ messages in thread From: Diego Novillo @ 2010-09-15 7:23 UTC (permalink / raw) To: Richard Guenther Cc: Ian Lance Taylor, Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero On Tue, Sep 14, 2010 at 06:09, Richard Guenther <richard.guenther@gmail.com> wrote: > On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor <iant@google.com> wrote: >> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: >> >>> In the same sense that adding clang->gcc means that there is less >>> motivation for developers to improve the current C/C++ FEs. >> >> From the perspective of gcc, I think the goal of clang->gcc would be to >> replace the current frontends entirely. > > Yes, doing clang->gcc would get us the C family frontends disentanglement > from the middle-end "for free". Indeed. I would be interested to know what our C/C++ maintainers think of this possibility. Jason, Mark, Joseph? Diego. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-15 7:23 ` Diego Novillo @ 2010-09-15 8:34 ` Joseph S. Myers 0 siblings, 0 replies; 90+ messages in thread From: Joseph S. Myers @ 2010-09-15 8:34 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc [-- Attachment #1: Type: TEXT/PLAIN, Size: 3424 bytes --] On Tue, 14 Sep 2010, Diego Novillo wrote: > On Tue, Sep 14, 2010 at 06:09, Richard Guenther > <richard.guenther@gmail.com> wrote: > > On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor <iant@google.com> wrote: > >> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > >> > >>> In the same sense that adding clang->gcc means that there is less > >>> motivation for developers to improve the current C/C++ FEs. > >> > >> From the perspective of gcc, I think the goal of clang->gcc would be to > >> replace the current frontends entirely. > > > > Yes, doing clang->gcc would get us the C family frontends disentanglement > > from the middle-end "for free". > > Indeed. I would be interested to know what our C/C++ maintainers > think of this possibility. Jason, Mark, Joseph? I think it's crazy on multiple grounds. * Most obviously for users, backwards compatibility. Replacing large user-visible pieces in mature code with an established user base is hopeless for compatibility. (I make no claims about the user base for GNU ObjC.) We should be working strictly with incremental development, avoiding regressions, improving compatibility with previous GCC releases where indicated by user feedback, not making massive changes that are bound to be incompatible - we haven't been careful enough about compatibility in the past. Maybe people working in middle-end pieces without much of a user-visible interface don't notice this. (Back ends do end up with quite a large interface - subtargets, options, pragmas, attributes, built-in functions, ... - that also makes them hard to replace safely, but that interface is far smaller than the front-end interface.) * Diversity in software (and hardware) implementations is intrinsically a good thing. I consider that one of the greatest problems in computer security today is an insufficiently diverse ecosystem; it would be much better if no front end, back end, programming language, operating system, hardware architecture, ... had more than maybe a 10% market share. It's also valuable for more than security if there are many implementations available to try and choose from for a particular purpose. Enabling combinations of front ends, optimizers, back ends from different places improves diversity; throwing out options reduces it. * The battle for software freedom and against closed computational devices and components for such devices must be fought on many fronts. I think a critical part of this is maintaining and improving the commons of copyleft, preferably GPLv3, software that is freely available for those who will preserve user freedom. When there is a choice of copyleft and non-copyleft free software in a particular area and the non-copyleft software is better in some way, the reaction should not be to replace the copyleft software, but to improve it, learning from the competition, and enhance the copyleft commons to encourage people to choose freedom and the greater amount of software available if they do so. And I very definitely consider the contribution to software freedom to be an important part of contributing to widely used copyleft software, and copyleft software generally to be a greater contribution to society, and so intrinsically more desirable to work on, than non-copyleft. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 13:18 ` Ian Lance Taylor 2010-09-14 14:14 ` Richard Guenther @ 2010-09-14 15:19 ` David Edelsohn 2010-09-14 17:00 ` Chris Lattner 1 sibling, 1 reply; 90+ messages in thread From: David Edelsohn @ 2010-09-14 15:19 UTC (permalink / raw) To: Ian Lance Taylor Cc: Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor <iant@google.com> wrote: > Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > >> In the same sense that adding clang->gcc means that there is less >> motivation for developers to improve the current C/C++ FEs. > > From the perspective of gcc, I think the goal of clang->gcc would be to > replace the current frontends entirely. Yes, I think it would be interesting to consider how Clang could evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be used by LLVM and GCC (and other FOSS compilers) -- an alternative to the EDG front-end. - David ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 15:19 ` David Edelsohn @ 2010-09-14 17:00 ` Chris Lattner 2010-09-14 17:14 ` Richard Guenther 2010-09-15 13:17 ` Kevin André 0 siblings, 2 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-14 17:00 UTC (permalink / raw) To: David Edelsohn Cc: Ian Lance Taylor, Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: > On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor <iant@google.com> wrote: >> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: >> >>> In the same sense that adding clang->gcc means that there is less >>> motivation for developers to improve the current C/C++ FEs. >> >> From the perspective of gcc, I think the goal of clang->gcc would be to >> replace the current frontends entirely. > > Yes, I think it would be interesting to consider how Clang could > evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be > used by LLVM and GCC (and other FOSS compilers) -- an alternative to > the EDG front-end. For what it is worth, this is something that the clang folk would certainly like to see happen. Clang is also already factored such that you don't need to pull in LLVM IR (and thus the llvm backend and code generator) if you don't want to. Just convert from clang ASTs to generic or gimple. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 17:00 ` Chris Lattner @ 2010-09-14 17:14 ` Richard Guenther 2010-09-15 13:17 ` Kevin André 1 sibling, 0 replies; 90+ messages in thread From: Richard Guenther @ 2010-09-14 17:14 UTC (permalink / raw) To: Chris Lattner Cc: David Edelsohn, Ian Lance Taylor, Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, dave.korn.cygwin, gcc, mikestump, nicola.pero On Tue, Sep 14, 2010 at 5:55 PM, Chris Lattner <clattner@apple.com> wrote: > > On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: > >> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor <iant@google.com> wrote: >>> Manuel López-Ibáñez <lopezibanez@gmail.com> writes: >>> >>>> In the same sense that adding clang->gcc means that there is less >>>> motivation for developers to improve the current C/C++ FEs. >>> >>> From the perspective of gcc, I think the goal of clang->gcc would be to >>> replace the current frontends entirely. >> >> Yes, I think it would be interesting to consider how Clang could >> evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be >> used by LLVM and GCC (and other FOSS compilers) -- an alternative to >> the EDG front-end. > > For what it is worth, this is something that the clang folk would certainly like to see happen. Clang is also already factored such that you don't need to pull in LLVM IR (and thus the llvm backend and code generator) if you don't want to. Just convert from clang ASTs to generic or gimple. Yes, that was my idea as well. I presume the most interesting part will be to get the types correct, the statement pieces should be straight-forward. If somebody wants to give it a try, I would simply create a new GCC frontend linking to Clang. Richard. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 17:00 ` Chris Lattner 2010-09-14 17:14 ` Richard Guenther @ 2010-09-15 13:17 ` Kevin André 2010-09-15 22:16 ` Chris Lattner 1 sibling, 1 reply; 90+ messages in thread From: Kevin André @ 2010-09-15 13:17 UTC (permalink / raw) To: Chris Lattner Cc: David Edelsohn, Ian Lance Taylor, Manuel López-Ibáñez, Steven Bosscher, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Tue, Sep 14, 2010 at 17:55, Chris Lattner <clattner@apple.com> wrote: > > On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: > >> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor <iant@google.com> wrote: >>> From the perspective of gcc, I think the goal of clang->gcc would be to >>> replace the current frontends entirely. >> >> Yes, I think it would be interesting to consider how Clang could >> evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be >> used by LLVM and GCC (and other FOSS compilers) -- an alternative to >> the EDG front-end. > > For what it is worth, this is something that the clang folk would certainly like to see happen. Clang is also already factored such that you don't need to pull in LLVM IR (and thus the llvm backend and code generator) if you don't want to. Just convert from clang ASTs to generic or gimple. Doesn't clang depend on LLVM libraries like LLVMSystem and LLVMSupport? ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-15 13:17 ` Kevin André @ 2010-09-15 22:16 ` Chris Lattner 0 siblings, 0 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-15 22:16 UTC (permalink / raw) To: Kevin André; +Cc: gcc On Sep 15, 2010, at 12:23 AM, Kevin André wrote: > On Tue, Sep 14, 2010 at 17:55, Chris Lattner <clattner@apple.com> wrote: >> >> On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: >> >>> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor <iant@google.com> wrote: >>>> From the perspective of gcc, I think the goal of clang->gcc would be to >>>> replace the current frontends entirely. >>> >>> Yes, I think it would be interesting to consider how Clang could >>> evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be >>> used by LLVM and GCC (and other FOSS compilers) -- an alternative to >>> the EDG front-end. >> >> For what it is worth, this is something that the clang folk would certainly like to see happen. Clang is also already factored such that you don't need to pull in LLVM IR (and thus the llvm backend and code generator) if you don't want to. Just convert from clang ASTs to generic or gimple. > > Doesn't clang depend on LLVM libraries like LLVMSystem and LLVMSupport? Yes, but those are very small libraries that don't pull in the llvm backend, code generator or llvm IR either. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 12:40 ` Manuel López-Ibáñez 2010-09-14 13:18 ` Ian Lance Taylor @ 2010-09-14 13:37 ` Steven Bosscher 1 sibling, 0 replies; 90+ messages in thread From: Steven Bosscher @ 2010-09-14 13:37 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Ian Lance Taylor, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Tue, Sep 14, 2010 at 12:30 AM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 14 September 2010 00:16, Steven Bosscher <stevenb.gcc@gmail.com> wrote: >> On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez >> <lopezibanez@gmail.com> wrote: >>>> I understand the benefit that existed before clang. And my general >>>> understanding is that clang C++ support is not yet complete, so there is >>>> a benefit there, but only a temporary one. I don't see a real benefit >>>> going forward. >>> >>> Access to all the other GCC front-ends that the LLVM project has not >>> (yet) reimplemented? Someone provided above a real user-case for >>> gcc->llvm involving Fortran. I don't think dragon-egg development is >>> stalled at all. >> >> And some (including yours truly) consider this little more than theft. >> Especially since there is GCC-bashing on the one side, and taking the >> bits they like on the other. >> >> >>>> Since for me benefits to users of gcc are pretty much the same as >>>> benefits to gcc, yes, I see a benefit. >>> >>> By that rule, it is clearly beneficial for some gcc users to compile >>> Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg >>> is beneficial to GCC. >> >> No it "is" not, you "think it is", i.e. opinion. Again, I don't share >> that opinion at all, because this means there is less motivation for >> developers to add OpenCL to GCC itself. > > In the same sense that adding clang->gcc means that there is less > motivation for developers to improve the current C/C++ FEs. So I guess > you are against this as well. But then, just a few mails above, you > are the one who proposed adding clang to gcc in the first place. > Sorry, it seems a contradiction to me and I cannot get my head around > it. So perhaps your guess is not right? You're using sophisms: First you "guess" what my goals are, and then you go on to show apparent contradictions. But actually, I think it may be the right thing for GCC to replace the front ends altogether with clang. Note: Maybe. There are clear advantages and disadvantages, and only time (and experimenting) will tell whether it will actually happen or not. Trying it with ObjC and ObjC++ first would be an interesting feasibility study. I personally do not believe that there is much value in maintaining GNU ObjC/ObjC++. The community of users is small and there are barely enough maintainers to sustain these front ends. In GCC, these languages will probably always be less important than C/C++, but in clang they are 1st class citizens. So what I meant to say in those "few mails above" is that time spent on plugging clang into gcc may be worth more than trying to forward-port about a decade of ObjC development from the Apple/NEXT compilers and runtimes to GCC. Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 10:13 ` Manuel López-Ibáñez 2010-09-14 11:14 ` Steven Bosscher @ 2010-09-14 12:05 ` Ian Lance Taylor 1 sibling, 0 replies; 90+ messages in thread From: Ian Lance Taylor @ 2010-09-14 12:05 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Jack Howarth, Paolo Bonzini, Steven Bosscher, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther Manuel López-Ibáñez <lopezibanez@gmail.com> writes: > By that rule, it is clearly beneficial for some gcc users to compile > Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg > is beneficial to GCC. That's pretty special purpose, though. Not something I would personally recommend that gcc developers work on. Ian ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-14 8:30 ` Manuel López-Ibáñez 2010-09-14 9:08 ` Ian Lance Taylor @ 2010-09-14 10:09 ` Steven Bosscher 1 sibling, 0 replies; 90+ messages in thread From: Steven Bosscher @ 2010-09-14 10:09 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Ian Lance Taylor, Jack Howarth, Paolo Bonzini, Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther On Mon, Sep 13, 2010 at 11:32 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > I think you are again talking about user benefits. You don't see a > (user) benefit in gcc->llvm because you perhaps do not use the > features that LLVM has and GCC doesn't. But users of gcc->llvm surely > see a large benefit if people have spent so much effort working on it, > first as a patched gcc and now as a plugin. And then replacing it. What's your point? Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:00 ` Richard Kenner 2010-09-10 13:09 ` Steven Bosscher @ 2010-09-10 13:12 ` Manuel López-Ibáñez 2010-09-10 13:35 ` Jack Howarth 2010-09-10 16:58 ` Mike Stump 2 siblings, 1 reply; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 13:12 UTC (permalink / raw) To: Richard Kenner Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, mikestump, nicola.pero, richard.guenther, stevenb.gcc On 10 September 2010 14:40, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: > > But if this were done, then it would be trivial to have proprietary > front ends, back ends, and optimizers. So RMS never allowed any such > thing nor any scheme that resulted in having any file that could be > used for such a purpose. As far as I know, you can currently plug GCC FEs to a proprietary LLVM middle-end using llvm-gcc. It is not a possibility but a reality (read the proceedings of the LLVM meetings). Just no one cares, because (a) the result is not publicly distributed (only internally or for research purposes) and (b) there is zero interest on contributing/integrating any code back to GCC from both sides. There are two issues, whether is possible technically to plug clang to GCC and whether is possible to create proprietary FEs to GCC. From Richard comments, the answer to the former is probably yes with perhaps less effort than Dragonegg. But that is not so important, because the answer to the latter is also yes right now by building a modified GCC (people have mentioned this in the lists). Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:12 ` Manuel López-Ibáñez @ 2010-09-10 13:35 ` Jack Howarth 2010-09-10 14:07 ` Manuel López-Ibáñez 0 siblings, 1 reply; 90+ messages in thread From: Jack Howarth @ 2010-09-10 13:35 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther, stevenb.gcc On Fri, Sep 10, 2010 at 03:09:02PM +0200, Manuel López-Ibáñez wrote: > On 10 September 2010 14:40, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: > > > > But if this were done, then it would be trivial to have proprietary > > front ends, back ends, and optimizers. So RMS never allowed any such > > thing nor any scheme that resulted in having any file that could be > > used for such a purpose. > > As far as I know, you can currently plug GCC FEs to a proprietary LLVM > middle-end using llvm-gcc. It is not a possibility but a reality (read > the proceedings of the LLVM meetings). Just no one cares, because (a) > the result is not publicly distributed (only internally or for > research purposes) and (b) there is zero interest on > contributing/integrating any code back to GCC from both sides. Huh? The dragon-egg gcc plugin to access llvm has been pubicly available since llvm 2.7... http://dragonegg.llvm.org/ http://dragonegg.llvm.org/#gettingrelease As to the second point, I believe that is entirely untrue (at least as far as patches required to build dragon-egg under FSF gcc is concerned). In the thread starting at http://gcc.gnu.org/ml/gcc/2010-04/msg00171.html, it is clear that Duncan Sands is interested in some level of coordination of dragon-egg development with FSF gcc. Jack > > There are two issues, whether is possible technically to plug clang to > GCC and whether is possible to create proprietary FEs to GCC. From > Richard comments, the answer to the former is probably yes with > perhaps less effort than Dragonegg. But that is not so important, > because the answer to the latter is also yes right now by building a > modified GCC (people have mentioned this in the lists). > > Cheers, > > Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:35 ` Jack Howarth @ 2010-09-10 14:07 ` Manuel López-Ibáñez 0 siblings, 0 replies; 90+ messages in thread From: Manuel López-Ibáñez @ 2010-09-10 14:07 UTC (permalink / raw) To: Jack Howarth Cc: Richard Kenner, Joe.Buck, clattner, dave.korn.cygwin, gcc, mikestump, nicola.pero, richard.guenther, stevenb.gcc On 10 September 2010 15:25, Jack Howarth <howarth@bromo.med.uc.edu> wrote: > On Fri, Sep 10, 2010 at 03:09:02PM +0200, Manuel López-Ibáñez wrote: >> On 10 September 2010 14:40, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: >> > >> > But if this were done, then it would be trivial to have proprietary >> > front ends, back ends, and optimizers. So RMS never allowed any such >> > thing nor any scheme that resulted in having any file that could be >> > used for such a purpose. >> >> As far as I know, you can currently plug GCC FEs to a proprietary LLVM >> middle-end using llvm-gcc. It is not a possibility but a reality (read >> the proceedings of the LLVM meetings). Just no one cares, because (a) >> the result is not publicly distributed (only internally or for >> research purposes) and (b) there is zero interest on >> contributing/integrating any code back to GCC from both sides. > > Huh? The dragon-egg gcc plugin to access llvm has been pubicly available > since llvm 2.7... I am not talking about the plugin. Plugins must be GPL. But the dragon-egg plugin does not make LLVM to fall under the GPL, nor any of the proprietary work that builds upon LLVM. Those are the ones I was referring to. Sorry if I didn't explain myself properly. I hope it is clear now. Cheers, Manuel. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:00 ` Richard Kenner 2010-09-10 13:09 ` Steven Bosscher 2010-09-10 13:12 ` Manuel López-Ibáñez @ 2010-09-10 16:58 ` Mike Stump 2 siblings, 0 replies; 90+ messages in thread From: Mike Stump @ 2010-09-10 16:58 UTC (permalink / raw) To: Richard Kenner Cc: lopezibanez, Joe.Buck, clattner, dave.korn.cygwin, gcc, howarth, nicola.pero, richard.guenther, stevenb.gcc On Sep 10, 2010, at 5:40 AM, Richard Kenner wrote: > More seriously, the issue is copyright law. In order to write a > front-end for GCC right now (or for a GCC front end to use another > backend), you have to use a sufficient number of header files and > interfaces of GCC that there's no question that it's a derived work > from GCC and hence must have a compatible license. Luckily, llvm and clang have a compatible license, so, we could have a llvm backend plugin, or a clang front-end plugin, if we want. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 12:20 ` Manuel López-Ibáñez 2010-09-10 12:21 ` Richard Kenner @ 2010-09-10 12:38 ` Richard Guenther 1 sibling, 0 replies; 90+ messages in thread From: Richard Guenther @ 2010-09-10 12:38 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Steven Bosscher, Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, Nicola Pero, gcc On Fri, Sep 10, 2010 at 2:16 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 10 September 2010 11:42, Richard Guenther <richard.guenther@gmail.com> wrote: >> On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: >> >>> Not that I want to discourage anyone. Just practical considerations... >>> ;-) I can't believe I'm saing this but: It may be better to spend >>> some effort on making clang work as a GCC front end. >> >> Oh, indeed - I'd welcome patches making "frontend plugins" possible >> and plugging clang. > > I wonder what would actually be needed to implement this? Since clang > keeps around more information than GCC's FEs. New plugin hooks? I > don't think you need FE plugins but a LLVM->GIMPLE converter plug to > the gimplifier. > > Is adding code to GCC to handle LLVM intermediate language acceptable? I think clang has its own intermediate language (aka parse tree). I'd write a clang -> GENERIC translator. The plugging place would be the various langhooks called by cgraphunit.c. Richard. > Cheers, > > Manuel. > ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:42 ` Richard Guenther 2010-09-10 12:20 ` Manuel López-Ibáñez @ 2010-09-10 13:37 ` Paulo J. Matos 2010-09-10 13:49 ` Steven Bosscher 2010-09-10 17:31 ` Mike Stump 2 siblings, 1 reply; 90+ messages in thread From: Paulo J. Matos @ 2010-09-10 13:37 UTC (permalink / raw) To: gcc Richard Guenther <richard.guenther@gmail.com> writes: > On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > >> Not that I want to discourage anyone. Just practical considerations... >> ;-) Â I can't believe I'm saing this but: It may be better to spend >> some effort on making clang work as a GCC front end. > > Oh, indeed - I'd welcome patches making "frontend plugins" possible > and plugging clang. > May I ask why would GCC want clang as a frontend? Would it supersede the current C frontend? -- PMatos ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 13:37 ` Paulo J. Matos @ 2010-09-10 13:49 ` Steven Bosscher 0 siblings, 0 replies; 90+ messages in thread From: Steven Bosscher @ 2010-09-10 13:49 UTC (permalink / raw) To: Paulo J. Matos; +Cc: gcc On Fri, Sep 10, 2010 at 3:35 PM, Paulo J. Matos <pocmatos@gmail.com> wrote: > May I ask why would GCC want clang as a frontend? Would it supersede the > current C frontend? I suppose not, but it could supersede the ObjC and ObjC++ front ends. And from there -- who knows. Ciao! Steven ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:42 ` Richard Guenther 2010-09-10 12:20 ` Manuel López-Ibáñez 2010-09-10 13:37 ` Paulo J. Matos @ 2010-09-10 17:31 ` Mike Stump 2 siblings, 0 replies; 90+ messages in thread From: Mike Stump @ 2010-09-10 17:31 UTC (permalink / raw) To: Richard Guenther Cc: Steven Bosscher, Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Nicola Pero, gcc On Sep 10, 2010, at 2:42 AM, Richard Guenther wrote: > On Fri, Sep 10, 2010 at 11:38 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: >> Not that I want to discourage anyone. Just practical considerations... >> ;-) I can't believe I'm saing this but: It may be better to spend >> some effort on making clang work as a GCC front end. > > Oh, indeed - I'd welcome patches making "frontend plugins" possible > and plugging clang. I'll check my patches in next week then. :-) ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:38 ` Steven Bosscher 2010-09-10 9:42 ` Richard Guenther @ 2010-09-10 10:56 ` Nicola Pero 2010-09-10 12:16 ` Richard Kenner 2010-09-10 11:47 ` Joseph S. Myers 2 siblings, 1 reply; 90+ messages in thread From: Nicola Pero @ 2010-09-10 10:56 UTC (permalink / raw) To: Steven Bosscher Cc: Richard Guenther, Joe Buck, Chris Lattner, Jack Howarth, Dave Korn, Mike Stump, gcc >> Btw, we do seem to have code in GCC that is not copyrighted by the FSF. >> For example I don't think the FSF owns copyright on the ACATS >> testsuite, and libffi mentions (c) by RedHat. > > That code is not part of the compiler proper. The policy has always > been different for the test suites and for runtime libraries. So is it Ok to import testcases (in this case, from Apple's own GCC) without a copyright assignment ? :-) If we're merging from a very old branch, with all the updates and changes required (and also, the changes required to support the GNU runtime), it would be helpful if we can test the final result against the same testcases used in Apple's GCC to make sure the resulting compiler (which will undoubtely have different internals) is at least not diverging too much in terms of behaviour. Thanks ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 10:56 ` Nicola Pero @ 2010-09-10 12:16 ` Richard Kenner 0 siblings, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 12:16 UTC (permalink / raw) To: nicola.pero Cc: clattner, dave.korn.cygwin, gcc, howarth, joe.buck, mikestump, richard.guenther, stevenb.gcc > So is it Ok to import testcases (in this case, from Apple's own GCC) > without a copyright assignment ? :-) I see the smiley, but I'd say the serious answer to that is that it might or might not be depending on what we knew about the copyright status of that code. If we knew (and this is the hard part!) through some means OTHER than the copyright notice in the files themselves that distributing these test case would not violate the copyright on them, then I think it would be fine to include them whether or not they were assigned to the FSF or whether the license was the GPL or not. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:38 ` Steven Bosscher 2010-09-10 9:42 ` Richard Guenther 2010-09-10 10:56 ` Nicola Pero @ 2010-09-10 11:47 ` Joseph S. Myers 2 siblings, 0 replies; 90+ messages in thread From: Joseph S. Myers @ 2010-09-10 11:47 UTC (permalink / raw) To: Steven Bosscher; +Cc: Nicola Pero, gcc On Fri, 10 Sep 2010, Steven Bosscher wrote: > * What standard is going to be implemented? ObjC 2.0 is not even a > documented language standard, so you probably end up with something > that is incompatible with Apple ObjC anyway. Without a documented > standard, the only "standard" is the Apple compiler, which you cannot > look at without risking copyright problems. The latest state of ObjC You certainly can build and run testcases with Apple's compilers to compare behavior (without looking at the sources), just as people looking at C++ tests exercising corner cases of the standard routinely compare with how EDG handles those areas (without having access to EDG sources). Independent implementations are of value in deciding how a language should be defined if it is not to be a language permanently defined by a particular implementation. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 9:13 ` Richard Guenther 2010-09-10 9:38 ` Steven Bosscher @ 2010-09-10 11:50 ` Richard Kenner 2010-09-10 12:10 ` Richard Kenner 2010-09-10 16:54 ` Mike Stump 1 sibling, 2 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 11:50 UTC (permalink / raw) To: richard.guenther Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, mikestump, nicola.pero > Btw, we do seem to have code in GCC that is not copyrighted by the FSF. > For example I don't think the FSF owns copyright on the ACATS > testsuite, and libffi mentions (c) by RedHat. For GCC as a project it > should matter that the code is distributable under GPLv3 which I think > Apples changes are. I thought the point is that Apple WON'T go to GPLv3. But I also think there are other cases where some code isn't under GPL and/or not assigned to the FSF. Things like crt0.c are derived from BSD code and are under the modified BSD license and there's also some public-domain code involved. > Copyright assignment to the FSF might be > convenient, but isn't legally necessary (only necessary by policy and > even that seems to have existing exceptions). I think there's a difference between the compiler proper and libraries and test suites. Because the latter are often derived from other code, my understanding is that the policy on license and copyright holder is less strict than the compiler itself, which doesn't have that problem. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 11:50 ` Richard Kenner @ 2010-09-10 12:10 ` Richard Kenner 2010-09-10 16:54 ` Mike Stump 1 sibling, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 12:10 UTC (permalink / raw) To: richard.guenther Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, mikestump, nicola.pero > Btw, we do seem to have code in GCC that is not copyrighted by the FSF. > For example I don't think the FSF owns copyright on the ACATS > testsuite, and libffi mentions (c) by RedHat. For GCC as a project it > should matter that the code is distributable under GPLv3 which I think > Apples changes are. I thought the point is that Apple WON'T go to GPLv3. But I also think there are other cases where some code isn't under GPL and/or not assigned to the FSF. Things like crt0.c are derived from BSD code and are under the modified BSD license and there's also some public-domain code involved. > Copyright assignment to the FSF might be > convenient, but isn't legally necessary (only necessary by policy and > even that seems to have existing exceptions). I think there's a difference between the compiler proper and libraries and test suites. Because the latter are often derived from other code, my understanding is that the policy on license and copyright holder is less strict than the compiler itself, which doesn't have that problem. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 11:50 ` Richard Kenner 2010-09-10 12:10 ` Richard Kenner @ 2010-09-10 16:54 ` Mike Stump 2010-09-10 18:49 ` Richard Kenner 1 sibling, 1 reply; 90+ messages in thread From: Mike Stump @ 2010-09-10 16:54 UTC (permalink / raw) To: Richard Kenner Cc: richard.guenther, Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero On Sep 10, 2010, at 4:52 AM, Richard Kenner wrote: > I thought the point is that Apple WON'T go to GPLv3. The Apple distributions are GPLv2 or later, meaning if someone wanted to take that code and distribute it under then GPLv3, they could. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 16:54 ` Mike Stump @ 2010-09-10 18:49 ` Richard Kenner 2010-09-10 20:24 ` Richard Kenner ` (2 more replies) 0 siblings, 3 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 18:49 UTC (permalink / raw) To: mikestump Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther > > I thought the point is that Apple WON'T go to GPLv3. > > The Apple distributions are GPLv2 or later, meaning if someone wanted to > take that code and distribute it under then GPLv3, they could. The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. FSF wants "GPLv3 or later" and it's not at all clear to me that we could change the license of code that's not copyright assigned to FSF to that license (we can for code that HAS been assigned). ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 18:49 ` Richard Kenner @ 2010-09-10 20:24 ` Richard Kenner 2010-09-10 20:39 ` Chris Lattner 2010-09-11 8:48 ` Mike Stump 2 siblings, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 20:24 UTC (permalink / raw) To: mikestump Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther > > I thought the point is that Apple WON'T go to GPLv3. > > The Apple distributions are GPLv2 or later, meaning if someone wanted to > take that code and distribute it under then GPLv3, they could. The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. FSF wants "GPLv3 or later" and it's not at all clear to me that we could change the license of code that's not copyright assigned to FSF to that license (we can for code that HAS been assigned). ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 18:49 ` Richard Kenner 2010-09-10 20:24 ` Richard Kenner @ 2010-09-10 20:39 ` Chris Lattner 2010-09-10 22:50 ` Chris Lattner 2010-09-10 23:05 ` Richard Kenner 2010-09-11 8:48 ` Mike Stump 2 siblings, 2 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-10 20:39 UTC (permalink / raw) To: Richard Kenner Cc: mikestump, Joe.Buck, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote: >>> I thought the point is that Apple WON'T go to GPLv3. >> >> The Apple distributions are GPLv2 or later, meaning if someone wanted to >> take that code and distribute it under then GPLv3, they could. > > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > change the license of code that's not copyright assigned to FSF to that > license (we can for code that HAS been assigned). The code in the apple branch on the fsf server *is* copyright assigned to the FSF. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 20:39 ` Chris Lattner @ 2010-09-10 22:50 ` Chris Lattner 2010-09-10 23:05 ` Richard Kenner 1 sibling, 0 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-10 22:50 UTC (permalink / raw) To: Richard Kenner Cc: mikestump, Joe.Buck, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote: >>> I thought the point is that Apple WON'T go to GPLv3. >> >> The Apple distributions are GPLv2 or later, meaning if someone wanted to >> take that code and distribute it under then GPLv3, they could. > > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > change the license of code that's not copyright assigned to FSF to that > license (we can for code that HAS been assigned). The code in the apple branch on the fsf server *is* copyright assigned to the FSF. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 20:39 ` Chris Lattner 2010-09-10 22:50 ` Chris Lattner @ 2010-09-10 23:05 ` Richard Kenner 2010-09-10 23:11 ` Richard Kenner 1 sibling, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-10 23:05 UTC (permalink / raw) To: clattner Cc: Joe.Buck, dave.korn.cygwin, gcc, gcc, howarth, mikestump, nicola.pero, richard.guenther > The code in the apple branch on the fsf server *is* copyright assigned to > the FSF. Right. That's why a previous email in this thread said there was no problem with them. I thought the remaining discussion was about files in OTHER places. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 23:05 ` Richard Kenner @ 2010-09-10 23:11 ` Richard Kenner 0 siblings, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-10 23:11 UTC (permalink / raw) To: clattner Cc: Joe.Buck, dave.korn.cygwin, gcc, gcc, howarth, mikestump, nicola.pero, richard.guenther > The code in the apple branch on the fsf server *is* copyright assigned to > the FSF. Right. That's why a previous email in this thread said there was no problem with them. I thought the remaining discussion was about files in OTHER places. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-10 18:49 ` Richard Kenner 2010-09-10 20:24 ` Richard Kenner 2010-09-10 20:39 ` Chris Lattner @ 2010-09-11 8:48 ` Mike Stump 2010-09-11 10:06 ` Mike Stump 2010-09-11 11:15 ` Richard Kenner 2 siblings, 2 replies; 90+ messages in thread From: Mike Stump @ 2010-09-11 8:48 UTC (permalink / raw) To: Richard Kenner Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote: > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > change the license of code that's not copyright assigned to FSF to that > license (we can for code that HAS been assigned). Ah, but the GPL v2 grants us that right. I'm not worried about that, but, it is irrelevant, as the FSF does not want to distribute that way, as they do want to be the sole owner (which means assignment). If in doubt and it mattered, we could ask the FSF lawyers, I think that would be non-issue. Where it would matter, is if the FSF was willing to distribute code they don't own exclusively in gcc/objc. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 8:48 ` Mike Stump @ 2010-09-11 10:06 ` Mike Stump 2010-09-11 11:15 ` Richard Kenner 1 sibling, 0 replies; 90+ messages in thread From: Mike Stump @ 2010-09-11 10:06 UTC (permalink / raw) To: Richard Kenner Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther On Sep 10, 2010, at 11:06 AM, Richard Kenner wrote: > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > change the license of code that's not copyright assigned to FSF to that > license (we can for code that HAS been assigned). Ah, but the GPL v2 grants us that right. I'm not worried about that, but, it is irrelevant, as the FSF does not want to distribute that way, as they do want to be the sole owner (which means assignment). If in doubt and it mattered, we could ask the FSF lawyers, I think that would be non-issue. Where it would matter, is if the FSF was willing to distribute code they don't own exclusively in gcc/objc. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 8:48 ` Mike Stump 2010-09-11 10:06 ` Mike Stump @ 2010-09-11 11:15 ` Richard Kenner 2010-09-11 18:09 ` Richard Kenner 2010-09-11 18:41 ` Mike Stump 1 sibling, 2 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-11 11:15 UTC (permalink / raw) To: mikestump Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther > > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > > change the license of code that's not copyright assigned to FSF to that > > license (we can for code that HAS been assigned). > > Ah, but the GPL v2 grants us that right. I disagree. The copyright holder has decided that they want people to (among other things) allow people to distribute under GPLv2. We can't take that away without the permission of that holder. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 11:15 ` Richard Kenner @ 2010-09-11 18:09 ` Richard Kenner 2010-09-11 18:41 ` Mike Stump 1 sibling, 0 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-11 18:09 UTC (permalink / raw) To: mikestump Cc: Joe.Buck, clattner, dave.korn.cygwin, gcc, gcc, howarth, nicola.pero, richard.guenther > > The fact that the licenses are COMPATIBLE doesn't make them IDENTICAL. > > FSF wants "GPLv3 or later" and it's not at all clear to me that we could > > change the license of code that's not copyright assigned to FSF to that > > license (we can for code that HAS been assigned). > > Ah, but the GPL v2 grants us that right. I disagree. The copyright holder has decided that they want people to (among other things) allow people to distribute under GPLv2. We can't take that away without the permission of that holder. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 11:15 ` Richard Kenner 2010-09-11 18:09 ` Richard Kenner @ 2010-09-11 18:41 ` Mike Stump 2010-09-11 18:48 ` Mike Stump 2010-09-11 20:59 ` Richard Kenner 1 sibling, 2 replies; 90+ messages in thread From: Mike Stump @ 2010-09-11 18:41 UTC (permalink / raw) To: Richard Kenner; +Cc: GCC Development, gcc On Sep 10, 2010, at 7:51 PM, Richard Kenner wrote: > I disagree. The copyright holder has decided that they want people to > (among other things) allow people to distribute under GPLv2. We can't > take that away without the permission of that holder. Well, the words on their distribution say exactly this: GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. That means, we at our option can choose to release under GPL v3, exclusively, if we wanted. Also, if there were a v4, we could release it under that exclusively, if we wanted. Further, would could release it under v3 or v4 at our option. Further, by induction, we could release it exclusively under v3 or later. Anyway, if you disagree, let's just leave it there, as this is already off-topic (gnu.misc.discuss if people want to continue discussions). ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 18:41 ` Mike Stump @ 2010-09-11 18:48 ` Mike Stump 2010-09-11 20:59 ` Richard Kenner 1 sibling, 0 replies; 90+ messages in thread From: Mike Stump @ 2010-09-11 18:48 UTC (permalink / raw) To: Richard Kenner; +Cc: GCC Development, gcc On Sep 10, 2010, at 7:51 PM, Richard Kenner wrote: > I disagree. The copyright holder has decided that they want people to > (among other things) allow people to distribute under GPLv2. We can't > take that away without the permission of that holder. Well, the words on their distribution say exactly this: GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. That means, we at our option can choose to release under GPL v3, exclusively, if we wanted. Also, if there were a v4, we could release it under that exclusively, if we wanted. Further, would could release it under v3 or v4 at our option. Further, by induction, we could release it exclusively under v3 or later. Anyway, if you disagree, let's just leave it there, as this is already off-topic (gnu.misc.discuss if people want to continue discussions). ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 18:41 ` Mike Stump 2010-09-11 18:48 ` Mike Stump @ 2010-09-11 20:59 ` Richard Kenner 2010-09-12 2:07 ` Ralf Wildenhues 1 sibling, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-11 20:59 UTC (permalink / raw) To: mikestump; +Cc: gcc > Well, the words on their distribution say exactly this: > > GCC is free software; you can redistribute it and/or modify it under > the terms of the GNU General Public License as published by the Free > Software Foundation; either version 2, or (at your option) any later > version. > > That means, we at our option can choose to release under GPL v3, > exclusively, if we wanted. I disagree, as I said. My interpretation of that sentence is that "when you redistribute this, you must give the person you redistribute it to the right to further redistribute it under EITHER GPLv2 OR GPLv3". Giving somebody the right to only redistribute under GPLv3 does NOT satisfy that requirement. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-11 20:59 ` Richard Kenner @ 2010-09-12 2:07 ` Ralf Wildenhues 2010-09-12 3:35 ` Richard Kenner 0 siblings, 1 reply; 90+ messages in thread From: Ralf Wildenhues @ 2010-09-12 2:07 UTC (permalink / raw) To: Richard Kenner; +Cc: mikestump, gcc Hello, * Richard Kenner wrote on Sat, Sep 11, 2010 at 01:18:10PM CEST: > > That means, we at our option can choose to release under GPL v3, > > exclusively, if we wanted. > > I disagree, as I said. > > My interpretation of that sentence is that "when you redistribute > this, you must give the person you redistribute it to the right to > further redistribute it under EITHER GPLv2 OR GPLv3". Giving somebody > the right to only redistribute under GPLv3 does NOT satisfy that > requirement. Please ask the FSF legal dept. to clarify the situation once and for all, they should be able to provide you with a binding (as for GCC) answer within a short time frame. This topic has come up on this list before, without obvious agreement from all parties afterwards, and is mostly off-topic here. Thank you, Ralf ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 2:07 ` Ralf Wildenhues @ 2010-09-12 3:35 ` Richard Kenner 2010-09-12 6:16 ` Ralf Wildenhues 0 siblings, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-12 3:35 UTC (permalink / raw) To: Ralf.Wildenhues; +Cc: gcc, mikestump > Please ask the FSF legal dept. to clarify the situation once and for > all, they should be able to provide you with a binding (as for GCC) > answer within a short time frame. It's my understanding that FSF legal department has consistently refused to answer such questions as this. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 3:35 ` Richard Kenner @ 2010-09-12 6:16 ` Ralf Wildenhues 2010-09-12 6:35 ` Richard Kenner 0 siblings, 1 reply; 90+ messages in thread From: Ralf Wildenhues @ 2010-09-12 6:16 UTC (permalink / raw) To: Richard Kenner; +Cc: gcc, mikestump * Richard Kenner wrote on Sat, Sep 11, 2010 at 11:01:56PM CEST: > > Please ask the FSF legal dept. to clarify the situation once and for > > all, they should be able to provide you with a binding (as for GCC) > > answer within a short time frame. > > It's my understanding that FSF legal department has consistently refused > to answer such questions as this. Do you have a quote for that, please? I remember otherwise, but only from conversation. Thanks, Ralf ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 6:16 ` Ralf Wildenhues @ 2010-09-12 6:35 ` Richard Kenner 2010-09-12 8:59 ` Jack Howarth ` (2 more replies) 0 siblings, 3 replies; 90+ messages in thread From: Richard Kenner @ 2010-09-12 6:35 UTC (permalink / raw) To: Ralf.Wildenhues; +Cc: gcc, mikestump > > It's my understanding that FSF legal department has consistently refused > > to answer such questions as this. > > Do you have a quote for that, please? How do you quote somebody who DOESN'T answer? The FSF has consistently refused to answer questions of the form "if I did XYZ, would it violate the GPL?" And I agree with that policy. (Note that this doesn't mean that the FSF doesn't have opinions about what maintainers of GNU software should do, but those are matters of POLICY, not saying "if you don't do that, you'll violate the GPL".) ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 6:35 ` Richard Kenner @ 2010-09-12 8:59 ` Jack Howarth 2010-09-13 10:30 ` Frank Ch. Eigler 2010-09-12 17:08 ` Dave Korn 2010-09-12 17:56 ` Ralf Wildenhues 2 siblings, 1 reply; 90+ messages in thread From: Jack Howarth @ 2010-09-12 8:59 UTC (permalink / raw) To: Richard Kenner; +Cc: Ralf.Wildenhues, gcc, mikestump On Sat, Sep 11, 2010 at 06:17:47PM -0400, Richard Kenner wrote: > > > It's my understanding that FSF legal department has consistently refused > > > to answer such questions as this. > > > > Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? > > The FSF has consistently refused to answer questions of the form "if I did > XYZ, would it violate the GPL?" And I agree with that policy. > > (Note that this doesn't mean that the FSF doesn't have opinions about > what maintainers of GNU software should do, but those are matters of > POLICY, not saying "if you don't do that, you'll violate the GPL".) Alternatively, perhaps Apple could clarify their own license file to clearly indicate that they do not prohibit their GPLv2 code from being relicensed as GPLv3-only code. After all, this doesn't really change the licensing status of Apple's changes in their gcc sources as they stay at GPLv2. Jack ps What examples are there of projects with GPLv3 licenses which aren't GPLv3 only (and allow code to be relicensed back as GPLv2)? ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 8:59 ` Jack Howarth @ 2010-09-13 10:30 ` Frank Ch. Eigler 0 siblings, 0 replies; 90+ messages in thread From: Frank Ch. Eigler @ 2010-09-13 10:30 UTC (permalink / raw) To: Jack Howarth; +Cc: Richard Kenner, Ralf.Wildenhues, gcc, mikestump Jack Howarth <howarth@bromo.med.uc.edu> writes: > [...] > Alternatively, perhaps Apple could clarify their own license file to > clearly indicate that they do not prohibit their GPLv2 code from being > relicensed as GPLv3-only code. After all, this doesn't really change > the licensing status of Apple's changes in their gcc sources as they stay > at GPLv2. There is no *licensing* problem with putting a piece of GPLv2+ code into a GPLv3+ application, or having a mixture of copyright holders. It's just that the FSF is not interested in merging such code into FSF GCC releases for policy reasons. (Anyone else could legally ship such a merged copy; see the FSF license compatibility matrix at http://www.gnu.org/licenses/gpl-faq.html) - FChE ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 6:35 ` Richard Kenner 2010-09-12 8:59 ` Jack Howarth @ 2010-09-12 17:08 ` Dave Korn 2010-09-12 17:56 ` Ralf Wildenhues 2 siblings, 0 replies; 90+ messages in thread From: Dave Korn @ 2010-09-12 17:08 UTC (permalink / raw) To: Richard Kenner; +Cc: Ralf.Wildenhues, gcc, mikestump On 11/09/2010 23:17, Richard Kenner wrote: >>> It's my understanding that FSF legal department has consistently refused >>> to answer such questions as this. >> Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? By using a null string, of course! cheers, DaveK ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 6:35 ` Richard Kenner 2010-09-12 8:59 ` Jack Howarth 2010-09-12 17:08 ` Dave Korn @ 2010-09-12 17:56 ` Ralf Wildenhues 2010-09-16 6:38 ` Ralf Wildenhues 2 siblings, 1 reply; 90+ messages in thread From: Ralf Wildenhues @ 2010-09-12 17:56 UTC (permalink / raw) To: Richard Kenner; +Cc: gcc, mikestump * Richard Kenner wrote on Sun, Sep 12, 2010 at 12:17:47AM CEST: > > > It's my understanding that FSF legal department has consistently refused > > > to answer such questions as this. > > > > Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? I've asked for you now. > The FSF has consistently refused to answer questions of the form "if I did > XYZ, would it violate the GPL?" Maybe, but this is such a simple question that I'm sure the GPL meant to address unambiguously, that I think it is worth trying to stop spreading uncertainty over. Cheers, Ralf ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-12 17:56 ` Ralf Wildenhues @ 2010-09-16 6:38 ` Ralf Wildenhues 2010-09-16 7:36 ` Richard Kenner 0 siblings, 1 reply; 90+ messages in thread From: Ralf Wildenhues @ 2010-09-16 6:38 UTC (permalink / raw) To: Richard Kenner, gcc, mikestump [ about modifying the license of "GPLv2 or later" or similarly licensed code ] * Ralf Wildenhues wrote on Sun, Sep 12, 2010 at 08:15:57AM CEST: > * Richard Kenner wrote on Sun, Sep 12, 2010 at 12:17:47AM CEST: > > > > It's my understanding that FSF legal department has consistently refused > > > > to answer such questions as this. > > > > > > Do you have a quote for that, please? > > > > How do you quote somebody who DOESN'T answer? FYI, quoting Brett Smith on this issue (with permission) below. Cheers, Ralf When the copyright holder of a program gives you permission to "redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version," they have given you permission to distribute it under the terms of any one or more of the licenses specified. Distributing the work under GPLv2-or-later, GPLv3-or-later, GPLv2-only, GPLv3-only, and so on are all permitted. It works the same way as disjunctive dual licenses: just like you have the option of distributing Perl under the terms of the Artistic License, the GPL, or both, you can do similarly here. If the license grant did not work this way, it would be unable to accomplish its intended goal of easing license compatibility issues when new versions of the GPL are released. With that said: I don't advise taking a GPLv2-or-later program and distributing it under GPLv3-or-later just because you can. That may upset some upstreams, and in general I don't like to see licensing become a point of contention between development teams like this. If you make this change, please do it for a specific reason. There are plenty of good ones (e.g., you've made changes that you want to clearly be under GPLv3, you want future contributors to provide a patent license under section 11, etc.), but developers should ideally have a solid sense of which of them are relevant for their project. Also note that just because you receive a work under GPLv2-or-later and distribute it under GPLv3-or-later doesn't necessarily mean that the previous distributor has new obligations. For example, if you get some GPLv2-or-later source from a distributor that has a tivoized product, you can't distribute that source under GPLv3-or-later and then turn around and ask the previous distributor for Installation Information. They're only on the hook to meet the conditions in one of the licenses they chose, which in this case would be GPLv2. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-16 6:38 ` Ralf Wildenhues @ 2010-09-16 7:36 ` Richard Kenner 2010-09-16 7:50 ` Robert Dewar 0 siblings, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-16 7:36 UTC (permalink / raw) To: Ralf.Wildenhues; +Cc: gcc, mikestump > FYI, quoting Brett Smith on this issue (with permission) below. > > When the copyright holder of a program gives you permission to > "redistribute it and/or modify it under the terms of the GNU General > Public License as published by the Free Software Foundation, either > version 2 of the License, or (at your option) any later version," they > have given you permission to distribute it under the terms of any one or > more of the licenses specified. I don't mean to keep this thread alive longer, but that answer is not to the question we've been discussing. OF COURSE you can "redistribute" a GPLv2-or-later file under GPLv3-or-later. That's never been the question! The question is whether you can RELICENSE a GPLv2-or-later file to be GPLv3-or-later without needing explicit permission of the copyright holder. To understand the difference, note that: > Also note that just because you receive a work under GPLv2-or-later and > distribute it under GPLv3-or-later doesn't necessarily mean that the > previous distributor has new obligations. For example, if you get some > GPLv2-or-later source from a distributor that has a tivoized product, > you can't distribute that source under GPLv3-or-later and then turn > around and ask the previous distributor for Installation Information. > They're only on the hook to meet the conditions in one of the licenses > they chose, which in this case would be GPLv2. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-16 7:36 ` Richard Kenner @ 2010-09-16 7:50 ` Robert Dewar 2010-09-16 8:55 ` Richard Kenner 0 siblings, 1 reply; 90+ messages in thread From: Robert Dewar @ 2010-09-16 7:50 UTC (permalink / raw) To: Richard Kenner; +Cc: Ralf.Wildenhues, gcc, mikestump On 9/15/2010 4:59 PM, Richard Kenner wrote: > I don't mean to keep this thread alive longer, but that answer is > not to the question we've been discussing. OF COURSE you can > "redistribute" a GPLv2-or-later file under GPLv3-or-later. That's > never been the question! > > The question is whether you can RELICENSE a GPLv2-or-later file to > be GPLv3-or-later without needing explicit permission of the copyright > holder. To understand the difference, note that: I do not understand the difference between "redistributing a file under a GPLv3-or-later license", and distributing it under a license that is GPLv3-or-later". Note that you can't necessarily even redistribute under GPL v3 if the work does not meet the criteria for such a distribution, e.g. it is Tivoized. > >> Also note that just because you receive a work under GPLv2-or-later and >> distribute it under GPLv3-or-later doesn't necessarily mean that the >> previous distributor has new obligations. For example, if you get some >> GPLv2-or-later source from a distributor that has a tivoized product, >> you can't distribute that source under GPLv3-or-later and then turn >> around and ask the previous distributor for Installation Information. >> They're only on the hook to meet the conditions in one of the licenses >> they chose, which in this case would be GPLv2. Well of course not, when A distributes B to C under license D, it is A who acquires the responsibility and obligations that acrue because of the distribution. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-16 7:50 ` Robert Dewar @ 2010-09-16 8:55 ` Richard Kenner 2010-09-16 14:18 ` Mike Stump 0 siblings, 1 reply; 90+ messages in thread From: Richard Kenner @ 2010-09-16 8:55 UTC (permalink / raw) To: dewar; +Cc: Ralf.Wildenhues, gcc, mikestump > I do not understand the difference between "redistributing a file > under a GPLv3-or-later license", and distributing it under a license > that is GPLv3-or-later". I'm not sure what the two things you list are, but the two that we're talking about are: (1) Distributing a GPLv2-or-later file as part of a GPV3-only or GPLV3-or-later package. Everybody agrees that you can do that. But when you do, the recipient of the file can choose to further redistribute it under GPLv2 if they want. (2) Changing the text at the front of the file to say "GPLv3-or-later" when it currently says "GPLv2-or-later". FSF *policy* (not the GPL) requires that all files have "GPLv3-or-later" license. The question is what permission you need to change a file that has a "GPLv2-or-later" license into the required one. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-16 8:55 ` Richard Kenner @ 2010-09-16 14:18 ` Mike Stump 0 siblings, 0 replies; 90+ messages in thread From: Mike Stump @ 2010-09-16 14:18 UTC (permalink / raw) To: Richard Kenner; +Cc: dewar, Ralf.Wildenhues, gcc On Sep 15, 2010, at 2:17 PM, Richard Kenner wrote: > FSF *policy* (not the GPL) requires that all files have "GPLv3-or-later" > license. The question is what permission you need to change a file > that has a "GPLv2-or-later" license into the required one. None, the GPL v2 clause grants this right, if it says GPL v2 or later. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 19:05 ` Dave Korn 2010-09-09 19:19 ` Jack Howarth @ 2010-09-09 21:09 ` Chris Lattner 1 sibling, 0 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-09 21:09 UTC (permalink / raw) To: Dave Korn; +Cc: Mike Stump, Nicola Pero, gcc On Sep 9, 2010, at 12:27 PM, Dave Korn wrote: > *Until and unless* Apple itself submits the code to the FSF, Apple retains > the copyright; which means that nobody else has the right to submit it to the > FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment > that allows them to sub-assign.... but that sounds even more complicated to me.) Right, that's why it is reasonable (to me) to assume that stuff in the apple branch on the fsf servers are fair game. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 10:11 Merging Apple's Objective-C 2.0 compiler changes Nicola Pero 2010-09-09 10:32 ` Nicola Pero 2010-09-09 11:02 ` Mike Stump @ 2010-09-09 17:09 ` Chris Lattner 2010-09-09 18:55 ` Nicola Pero 2010-11-02 15:31 ` Ed Smith-Rowland 3 siblings, 1 reply; 90+ messages in thread From: Chris Lattner @ 2010-09-09 17:09 UTC (permalink / raw) To: Nicola Pero; +Cc: gcc, Mike Stump On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: > Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to GCC into FSF GCC trunk ? > Any legal obstacles ? > > If we start producing patches to the current FSF GCC trunk that merge these modifications, would they be accepted ? > > I think Apple would benefit from merging of their modifications in that we'd merge the Apple/NeXT runtime support as well. :-) > They don't have to do any work. Be aware that none of the changes that haven't been committed to the FSF trees are copyright-assigned to the FSF. In practice, since the FSF cares about copyright assignment, this probably means that you can probably merge whatever is in the apple branch on the FSF server, but you can't take things out of llvm-gcc or the apple gcc tarballs that get pushed out on opendarwin. I'm not a lawyer, so this isn't legal advice, just my understanding of FSF policies and the mechanics of how the copyright transfer works. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 17:09 ` Chris Lattner @ 2010-09-09 18:55 ` Nicola Pero 2010-09-09 21:13 ` Chris Lattner 0 siblings, 1 reply; 90+ messages in thread From: Nicola Pero @ 2010-09-09 18:55 UTC (permalink / raw) To: Chris Lattner; +Cc: gcc, Mike Stump Chris thanks a lot for your answer. That makes sense - I had not realized that most of the Apple GCC Objective-C / Objective-C++ changes were already sitting on the FSF servers in an Apple branch :-) Can someone from the FSF confirm that it's OK to merge code from there ? I did look at the branch, and it contains most of the functionality (so it's very useful) but unfortunately it's quite old (eg. it's still using c-parse.in to parse). Why don't you upload one of the recent Apple GCC tarballs in a branch on the FSF server ? It won't change/cost anything for Apple (the code is already distributed to the world under GPL v2+) but it means changes could be merged back into the FSF GCC which could have much better support for Apple platforms. More choice of compilers for Apple users is surely good for Apple. :-) You don't have to do it, but contributing changes back to the original project seems to be the right, honourable thing to do, particularly when it doesn't cost anything. And most/all improvements you make to GCC are for Apple machines, so certainly you want these improvements back into the FSF GCC to get more software work on Apple machines and sell more of them. :-) Thanks ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 18:55 ` Nicola Pero @ 2010-09-09 21:13 ` Chris Lattner 0 siblings, 0 replies; 90+ messages in thread From: Chris Lattner @ 2010-09-09 21:13 UTC (permalink / raw) To: Nicola Pero; +Cc: gcc, Mike Stump On Sep 9, 2010, at 11:55 AM, Nicola Pero wrote: > Why don't you upload one of the recent Apple GCC tarballs in a branch on the FSF server ? > ... > You don't have to do it, but contributing changes back to the original project seems to be the right, honourable thing to do, particularly when it doesn't cost anything. Hi Nicola, I don't have the authority to do this, it is not my copyright to assign. -Chris ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-09-09 10:11 Merging Apple's Objective-C 2.0 compiler changes Nicola Pero ` (2 preceding siblings ...) 2010-09-09 17:09 ` Chris Lattner @ 2010-11-02 15:31 ` Ed Smith-Rowland 2010-11-02 17:23 ` Nicola Pero 2010-11-02 17:56 ` Jonathan Wakely 3 siblings, 2 replies; 90+ messages in thread From: Ed Smith-Rowland @ 2010-11-02 15:31 UTC (permalink / raw) To: Nicola Pero; +Cc: gcc, Mike Stump, developer Nicola, Iain, Mike, It would be great if you all could update http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great work that has gone into Objective-C++ recently. Those of us hoping to play with the new Objective-C want to know. ;-) Thank you, Ed ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-11-02 15:31 ` Ed Smith-Rowland @ 2010-11-02 17:23 ` Nicola Pero 2010-11-02 17:56 ` Jonathan Wakely 1 sibling, 0 replies; 90+ messages in thread From: Nicola Pero @ 2010-11-02 17:23 UTC (permalink / raw) To: Ed Smith-Rowland; +Cc: gcc, Mike Stump, developer It'll be very happy to do that; I like writing documentation. But yesterday night I was playing with testcases for @property from the Apple llvm-gcc compiler and realized a number of problems in our implementation. I want to fix these first as some of them are major bugs and I want to fix them early in the bug-fixing phase. It will take me a few days. Then I'll come back and work on the release notes. :-) Thanks -----Original Message----- From: "Ed Smith-Rowland" <3dw4rd@verizon.net> Sent: Tuesday, 2 November, 2010 16:13 To: "Nicola Pero" <nicola.pero@meta-innovation.com> Cc: gcc@gnu.org, "Mike Stump" <mikestump@comcast.net>, developer@sandoe-acoustics.co.uk Subject: Re: Merging Apple's Objective-C 2.0 compiler changes Nicola, Iain, Mike, It would be great if you all could update http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great work that has gone into Objective-C++ recently. Those of us hoping to play with the new Objective-C want to know. ;-) Thank you, Ed ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Merging Apple's Objective-C 2.0 compiler changes 2010-11-02 15:31 ` Ed Smith-Rowland 2010-11-02 17:23 ` Nicola Pero @ 2010-11-02 17:56 ` Jonathan Wakely 1 sibling, 0 replies; 90+ messages in thread From: Jonathan Wakely @ 2010-11-02 17:56 UTC (permalink / raw) To: Ed Smith-Rowland; +Cc: Nicola Pero, gcc, Mike Stump, developer On 2 November 2010 15:13, Ed Smith-Rowland wrote: > > It would be great if you all could update > http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great > work that has gone into Objective-C++ recently. http://gcc.gnu.org/gcc-4.6/changes.html would make more sense! ^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2010-11-02 17:23 UTC | newest] Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-09-09 10:11 Merging Apple's Objective-C 2.0 compiler changes Nicola Pero 2010-09-09 10:32 ` Nicola Pero 2010-09-09 11:36 ` Richard Kenner 2010-09-09 11:02 ` Mike Stump 2010-09-09 19:05 ` Dave Korn 2010-09-09 19:19 ` Jack Howarth 2010-09-09 19:30 ` Dave Korn 2010-09-09 21:12 ` Chris Lattner 2010-09-10 0:18 ` Joe Buck 2010-09-10 9:13 ` Richard Guenther 2010-09-10 9:38 ` Steven Bosscher 2010-09-10 9:42 ` Richard Guenther 2010-09-10 12:20 ` Manuel López-Ibáñez 2010-09-10 12:21 ` Richard Kenner 2010-09-10 12:28 ` Manuel López-Ibáñez 2010-09-10 13:00 ` Richard Kenner 2010-09-10 13:09 ` Steven Bosscher 2010-09-10 13:13 ` Manuel López-Ibáñez 2010-09-10 13:16 ` Manuel López-Ibáñez 2010-09-13 14:55 ` Paolo Bonzini 2010-09-13 15:22 ` Paolo Bonzini 2010-09-13 15:55 ` Manuel López-Ibáñez 2010-09-13 21:48 ` Jack Howarth 2010-09-13 22:06 ` Manuel López-Ibáñez 2010-09-13 22:27 ` Ian Lance Taylor 2010-09-13 22:33 ` Marcus Daniels 2010-09-14 8:30 ` Manuel López-Ibáñez 2010-09-14 9:08 ` Ian Lance Taylor 2010-09-14 10:13 ` Manuel López-Ibáñez 2010-09-14 11:14 ` Steven Bosscher 2010-09-14 12:40 ` Manuel López-Ibáñez 2010-09-14 13:18 ` Ian Lance Taylor 2010-09-14 14:14 ` Richard Guenther 2010-09-15 7:23 ` Diego Novillo 2010-09-15 8:34 ` Joseph S. Myers 2010-09-14 15:19 ` David Edelsohn 2010-09-14 17:00 ` Chris Lattner 2010-09-14 17:14 ` Richard Guenther 2010-09-15 13:17 ` Kevin André 2010-09-15 22:16 ` Chris Lattner 2010-09-14 13:37 ` Steven Bosscher 2010-09-14 12:05 ` Ian Lance Taylor 2010-09-14 10:09 ` Steven Bosscher 2010-09-10 13:12 ` Manuel López-Ibáñez 2010-09-10 13:35 ` Jack Howarth 2010-09-10 14:07 ` Manuel López-Ibáñez 2010-09-10 16:58 ` Mike Stump 2010-09-10 12:38 ` Richard Guenther 2010-09-10 13:37 ` Paulo J. Matos 2010-09-10 13:49 ` Steven Bosscher 2010-09-10 17:31 ` Mike Stump 2010-09-10 10:56 ` Nicola Pero 2010-09-10 12:16 ` Richard Kenner 2010-09-10 11:47 ` Joseph S. Myers 2010-09-10 11:50 ` Richard Kenner 2010-09-10 12:10 ` Richard Kenner 2010-09-10 16:54 ` Mike Stump 2010-09-10 18:49 ` Richard Kenner 2010-09-10 20:24 ` Richard Kenner 2010-09-10 20:39 ` Chris Lattner 2010-09-10 22:50 ` Chris Lattner 2010-09-10 23:05 ` Richard Kenner 2010-09-10 23:11 ` Richard Kenner 2010-09-11 8:48 ` Mike Stump 2010-09-11 10:06 ` Mike Stump 2010-09-11 11:15 ` Richard Kenner 2010-09-11 18:09 ` Richard Kenner 2010-09-11 18:41 ` Mike Stump 2010-09-11 18:48 ` Mike Stump 2010-09-11 20:59 ` Richard Kenner 2010-09-12 2:07 ` Ralf Wildenhues 2010-09-12 3:35 ` Richard Kenner 2010-09-12 6:16 ` Ralf Wildenhues 2010-09-12 6:35 ` Richard Kenner 2010-09-12 8:59 ` Jack Howarth 2010-09-13 10:30 ` Frank Ch. Eigler 2010-09-12 17:08 ` Dave Korn 2010-09-12 17:56 ` Ralf Wildenhues 2010-09-16 6:38 ` Ralf Wildenhues 2010-09-16 7:36 ` Richard Kenner 2010-09-16 7:50 ` Robert Dewar 2010-09-16 8:55 ` Richard Kenner 2010-09-16 14:18 ` Mike Stump 2010-09-09 21:09 ` Chris Lattner 2010-09-09 17:09 ` Chris Lattner 2010-09-09 18:55 ` Nicola Pero 2010-09-09 21:13 ` Chris Lattner 2010-11-02 15:31 ` Ed Smith-Rowland 2010-11-02 17:23 ` Nicola Pero 2010-11-02 17:56 ` Jonathan Wakely
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).