Merging Apple's Objective-C 2.0 compiler changes

Merging Apple's Objective-C 2.0 compiler changes

[Nicola Pero]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Nicola Pero]

> 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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[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 ?

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/*.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Dave Korn]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Jack Howarth]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Dave Korn]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Joe Buck]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Guenther]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Guenther]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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!

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Paolo Bonzini]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Paolo Bonzini]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Jack Howarth]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ian Lance Taylor]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Marcus Daniels]

  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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ian Lance Taylor]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ian Lance Taylor]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Guenther]

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
>

Re: Merging Apple's Objective-C 2.0 compiler changes

[Diego Novillo]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Joseph S. Myers]

[-- 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

Re: Merging Apple's Objective-C 2.0 compiler changes

[David Edelsohn]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Guenther]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Kevin André]

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?

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ian Lance Taylor]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Jack Howarth]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Manuel López-Ibáñez]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Guenther]

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.
>

Re: Merging Apple's Objective-C 2.0 compiler changes

[Paulo J. Matos]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Steven Bosscher]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.  :-)

Re: Merging Apple's Objective-C 2.0 compiler changes

[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.
>
> 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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Joseph S. Myers]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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).

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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).

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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).

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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).

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ralf Wildenhues]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ralf Wildenhues]

* 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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> > 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".)

Re: Merging Apple's Objective-C 2.0 compiler changes

[Jack Howarth]

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)?

Re: Merging Apple's Objective-C 2.0 compiler changes

[Frank Ch. Eigler]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Dave Korn]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ralf Wildenhues]

* 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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ralf Wildenhues]

[ 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Robert Dewar]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Richard Kenner]

> 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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Mike Stump]

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.

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Nicola Pero]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Chris Lattner]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ed Smith-Rowland]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Nicola Pero]

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

Re: Merging Apple's Objective-C 2.0 compiler changes

[Jonathan Wakely]

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!