ObjC - another bugfix merge from apple/trunk

Another bugfix merge from the apple/trunk branch ... this fixes an internal compiler error while compiling ObjC++.

Committed to trunk.

Thanks

PS: Apologies for merging bug fixes one by one ... I like to understand exactly each change 
that I'm committing, and it allows me to work on them incrementally in small chunks

On Thu, Sep 30, 2010 at 10:36 AM, Nicola Pero
<nicola.pero@meta-innovation.com> wrote:
> Another bugfix merge from the apple/trunk branch ... this fixes an internal compiler error while compiling ObjC++.
>
> Committed to trunk.
>
> Thanks
>
> PS: Apologies for merging bug fixes one by one ... I like to understand exactly each change
> that I'm committing, and it allows me to work on them incrementally in small chunks

Well, I think that's exactly the right thing to do (otherwise I guess I would
have complained already ;)).

Thanks,
Richard.

> Index: gcc/objc/objc-act.c
> ===================================================================
> --- gcc/objc/objc-act.c (revision 164744)
> +++ gcc/objc/objc-act.c (working copy)
> @@ -3092,7 +3092,9 @@ objc_declare_class (tree ident_list)
>          if (record)
>            {
>              if (TREE_CODE (record) == TYPE_DECL)
> -               type = DECL_ORIGINAL_TYPE (record);
> +               type = DECL_ORIGINAL_TYPE (record) ?
> +                       DECL_ORIGINAL_TYPE (record) :
> +                       TREE_TYPE (record);
>
>              if (!TYPE_HAS_OBJC_INFO (type)
>                  || !TYPE_OBJC_INTERFACE (type))
> Index: gcc/objc/ChangeLog
> ===================================================================
> --- gcc/objc/ChangeLog  (revision 164744)
> +++ gcc/objc/ChangeLog  (working copy)
> @@ -1,3 +1,13 @@
> +2010-09-30  Nicola Pero  <nicola.pero@meta-innovation.com>
> +
> +       Merge from 'apple/trunk' branch on FSF servers.
> +
> +       2005-10-04  Fariborz Jahanian <fjahanian@apple.com>
> +
> +       Radar 4278236
> +       * objc-act.c (objc_declare_class): Pick the right
> +       type tree.
> +
>  2010-09-29  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        Merge from 'apple/trunk' branch on FSF servers.
> Index: gcc/testsuite/ChangeLog
> ===================================================================
> --- gcc/testsuite/ChangeLog     (revision 164744)
> +++ gcc/testsuite/ChangeLog     (working copy)
> @@ -1,3 +1,12 @@
> +2010-09-30  Nicola Pero  <nicola.pero@meta-innovation.com>
> +
> +       Merge from 'apple/trunk' branch on FSF servers.
> +
> +       2005-10-04  Fariborz Jahanian <fjahanian@apple.com>
> +
> +       Radar 4278236
> +       * obj-c++.dg/bad-forward-decl.mm: New
> +
>  2010-09-30  Eric Botcazou  <ebotcazou@adacore.com>
>
>        * ada/acats/run_acats: Revert revision 157037.
> Index: gcc/testsuite/obj-c++.dg/bad-forward-decl.mm
> ===================================================================
> --- gcc/testsuite/obj-c++.dg/bad-forward-decl.mm        (revision 0)
> +++ gcc/testsuite/obj-c++.dg/bad-forward-decl.mm        (revision 0)
> @@ -0,0 +1,3 @@
> +class TestCPP { };     /* { dg-error "previous declaration of" } */
> +
> +@class TestCPP;                /* { dg-error "redeclared as different kind of symbol" } */
>
>
>

On Sep 30, 2010, at 1:36 AM, "Nicola Pero" <nicola.pero@meta-innovation.com> wrote:
> PS: Apologies for merging bug fixes one by one ... I like to understand exactly each change 
> that I'm committing, and it allows me to work on them incrementally in small chunks

One by one is fine with me, the only problem would be if you stop before all is done it will be harder for someone else to figure out what remains to be done.
>

On Thu, Sep 30, 2010 at 5:22 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Sep 30, 2010, at 1:36 AM, "Nicola Pero" <nicola.pero@meta-innovation.com> wrote:
>> PS: Apologies for merging bug fixes one by one ... I like to understand exactly each change
>> that I'm committing, and it allows me to work on them incrementally in small chunks
>
> One by one is fine with me, the only problem would be if you stop before all is done it will be harder for someone else to figure out what remains to be done.

True.  You could merge from trunk to the branch (or a copy of it), but I
don't know if that is feasible.

Richard.
>

On 30 Sep 2010, at 16:34, Richard Guenther wrote:

> On Thu, Sep 30, 2010 at 5:22 PM, Mike Stump <mikestump@comcast.net>  
> wrote:
>> On Sep 30, 2010, at 1:36 AM, "Nicola Pero" <nicola.pero@meta-innovation.com 
>> > wrote:
>>> PS: Apologies for merging bug fixes one by one ... I like to  
>>> understand exactly each change
>>> that I'm committing, and it allows me to work on them  
>>> incrementally in small chunks
>>
>> One by one is fine with me, the only problem would be if you stop  
>> before all is done it will be harder for someone else to figure out  
>> what remains to be done.
>
> True.  You could merge from trunk to the branch (or a copy of it),  
> but I
> don't know if that is feasible.

we're keeping the radar numbers in our merges and,  or the most  
part,   since there is significant divergence in the trees (esp. in  
the c part) the merges have to be manual...

I'm also much happier with piece-by-piece ..
Iain

> One by one is fine with me, the only problem would be 
> if you stop before all is done it will be harder 
> for someone else to figure out what remains to be done.

Yes.

To help with that, I'm keeping the "Radar" numbers in the ChangeLogs,
and since the end of last week I also started going chronologically 
(following changelog entries in gcc/objc/ChangeLog.apple-ppc). :-)

I skipped 4136489, 4292010 and 4280641, but other than that, I merged
everything in gcc/objc up to 2005-10-04 into trunk.

The disadvantage is that I'm obviously eager to merge Objective-C 2.0, stuff,
but because I'm going chronologically, I'm currently mostly merging bugfixes.

On the other hand, I don't want to leave any bugfix on the table. ;-)
It's so much easier to merge code than to write new one. ;-)

Thanks

> To help with that, I'm keeping the "Radar" numbers in the ChangeLogs,

That will help, but radar numbers aren't the be-all end-all of the changes.  In the end, it is the diff from gcc-4.2.1 to the branch.  The APPLE LOCAL markers are complete and will identify everything.