Fwd: Unreviewed patch [was : PATCH: Protocol Warning]

Fwd: Unreviewed patch [was : PATCH: Protocol Warning]

[Devang Patel]

I would like to get this in before stage 3 begins.
Is it possible for someone to review this?

Thank you,
-Devang

Begin forwarded message:

> From: Devang Patel <dpatel@apple.com>
> Date: Tue Aug 6, 2002  1:54:34  PM US/Pacific
> To: gcc-patches@gcc.gnu.org
> Subject: Fwd: Unreviewed patch [was : PATCH: Protocol Warning]
>
> This is still unreviewed. I would appreciate if somebody say something.
> Thank you,
>
> -Devang
>
> Begin forwarded message:
>
>> From: Devang Patel <dpatel@apple.com>
>> Date: Wed Jul 31, 2002  6:04:42  PM US/Pacific
>> To: gcc-patches@gcc.gnu.org
>> Subject: Unreviewed patch [was : PATCH: Protocol Warning]
>>
>> Well, It passes check-g++ and check-gcc test.
>>
>> -Devang
>>
>> On Thursday, July 25, 2002, at 08:39  PM, Stan Shebs wrote:
>>
>>> Devang Patel wrote:
>>>
>>>>
>>>> For the given test case, in Objective C, protocol 'qualified id'
>>>> is incorrectly used for another 'id'. This happens when
>>>> get_qualified_type () is tring to reuse existing TYPE.
>>>>
>>>> This simple patch adds one extra condition while deciding
>>>> if a existing TYPE is suitable or not.
>>>>
>>>> Bootstrapped and passes testsuite check.
>>>
>>> From the ObjC point of view this is fine, but I'm not certain about
>>> how this impacts the several other clients of get_qualified_type.
>>> Could someone more knowledgeable look at this please?
>>>
>>> Stan
>>>
>>>>
>>>> -Devang
>>>>
>>>> 07-24-2002 Devang Patel <dpatel@apple.com>
>>>>         * tree.c (get_qualified_type): Add TYPE_CONTEXT check.
>>>>
>>>> testsuite:
>>>>         * objc.dg/proto-hier-2.m: New test.
>>>>
>>>>
>>>> Index: tree.c
>>>> ===================================================================
>>>> RCS file: /cvs/gcc/gcc/gcc/tree.c,v
>>>> retrieving revision 1.268
>>>> diff -c -3 -p -r1.268 tree.c
>>>> *** tree.c      23 Jul 2002 21:58:56 -0000      1.268
>>>> --- tree.c      25 Jul 2002 23:53:00 -0000
>>>> *************** get_qualified_type (type, type_quals)
>>>> *** 2866,2872 ****
>>>>        like the one we need to have.  If so, use that existing one. 
>>>>  We must
>>>>        preserve the TYPE_NAME, since there is code that depends on 
>>>> this.  */
>>>>     for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
>>>> !     if (TYPE_QUALS (t) == type_quals && TYPE_NAME (t) == 
>>>> TYPE_NAME (type))
>>>>         return t;
>>>>
>>>>     return NULL_TREE;
>>>> --- 2866,2873 ----
>>>>        like the one we need to have.  If so, use that existing one. 
>>>>  We must
>>>>        preserve the TYPE_NAME, since there is code that depends on 
>>>> this.  */
>>>>     for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
>>>> !     if (TYPE_QUALS (t) == type_quals && TYPE_NAME (t) == 
>>>> TYPE_NAME (type)
>>>> !         && TYPE_CONTEXT (t) == TYPE_CONTEXT (type))
>>>>         return t;
>>>>
>>>>     return NULL_TREE;
>>>> Index: testsuite/objc.dg/proto-hier-2.m
>>>> ===================================================================
>>>> RCS file: testsuite/objc.dg/proto-hier-2.m
>>>> diff -N testsuite/objc.dg/proto-hier-2.m
>>>> *** /dev/null   1 Jan 1970 00:00:00 -0000
>>>> --- testsuite/objc.dg/proto-hier-2.m    25 Jul 2002 23:53:00 -0000
>>>> ***************
>>>> *** 0 ****
>>>> --- 1,49 ----
>>>> + /* Test protocol warning.  */
>>>> + /* Contributed by Devang Patel <dpatel@apple.com>.  */
>>>> + /* { dg-do compile } */
>>>> +
>>>> + typedef struct objc_object { struct objc_class *class_pointer; } 
>>>> *id;
>>>> +
>>>> + @protocol Bar
>>>> + @end
>>>> +
>>>> + id <Bar> Foo_Bar () { }
>>>> +
>>>> + typedef struct
>>>> + {
>>>> +         int i;
>>>> + } MyStruct;
>>>> +
>>>> + @interface Foo
>>>> + {
>>>> +   id _mainData;
>>>> +   MyStruct *_anotherData;
>>>> + }
>>>> +
>>>> + -(id) mainDataSource;
>>>> + -(id) anotherDataSource;
>>>> + -(id) my_method: (int) i;
>>>> + @end
>>>> +
>>>> + @implementation Foo
>>>> + -(id) anotherDataSource
>>>> + {
>>>> +         return (id)_anotherData;
>>>> + }
>>>> +
>>>> + -(id) mainDataSource
>>>> + {
>>>> +         return _mainData;
>>>> + }
>>>> +
>>>> + -(id) my_method: (int) i
>>>> + {
>>>> +   id one = [self anotherDataSource];
>>>> +
>>>> +   i = i - 1;
>>>> +   // Do not issue warning about my_method not implemented by 
>>>> protocol
>>>> +   return [(one ? [self mainDataSource] : one) my_method:i];
>>>> + }
>>>> +
>>>> + @end
>>>> +
>>>>
>>>>

Re: GCC 3.3 Stage 3 Reminder

[Gerald Pfeifer]

On Mon, 12 Aug 2002, Mark Mitchell wrote:
> This email is a reminder that Stage 3 for GCC 3.3 begins August 15th.
> [...]
> I will send another announcement when we reach that point.

I'll be offline starting that day, so a brief reminder that someone please
also updates our main page accordingly (under "Active development").

On Tue, 13 Aug 2002, Andrew Haley wrote:
> The Java tree inliner patch was submitted a little time ago.  I
> suspect that it is unlikely to be reviewed before August 15th, but IMO
> it should go into GCC 3.3 anyway as it fixes a performance regression
> from earlier releases.

Personally, I think we should try to have an arrangement where patches
submitted before the cut-off date can (and in fact should) be considered
during the first one or two weeks of stage 3.

That would, at least that's my idea, provide a bit of fairness.

On Mon, 12 Aug 2002, Devang Patel wrote:
> I would like to get this in before stage 3 begins.
> Is it possible for someone to review this?

Similiar for Devang's patch, which he submitted more than two weeks
before the cut-off date.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.3 Stage 3 Reminder

[Mark Mitchell]

--On Wednesday, August 14, 2002 12:39:06 AM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> On Mon, 12 Aug 2002, Mark Mitchell wrote:
>> This email is a reminder that Stage 3 for GCC 3.3 begins August 15th.
>> [...]
>> I will send another announcement when we reach that point.
>
> I'll be offline starting that day, so a brief reminder that someone please
> also updates our main page accordingly (under "Active development").

I'll take care of that.

Thanks for the reminder!

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.3 Stage 3 Reminder

[Devang Patel]

On Tuesday, August 13, 2002, at 03:39  PM, Gerald Pfeifer wrote:

>
> On Mon, 12 Aug 2002, Devang Patel wrote:
>> I would like to get this in before stage 3 begins.
>> Is it possible for someone to review this?
>
> Similiar for Devang's patch, which he submitted more than two weeks
> before the cut-off date.

Gerald,

I appreciate that you remembered my unreviewed patch.
But frankly speaking, I have no hope that it will be part of GCC 3.3

However I do want it to be included in GCC 3.3, but since I posted
original patch on July 25th (followed by three reminder, one each week)
it has fetched only *one* response. That response is an approval from
Stan as far as  Objective-C is concerned, but he asked to wait for
approval from tree.c expert.

-Devang

"In the beginning the universe was created.
  This has widely been regarded as a bad move."  - Douglas Adams

Re: Fwd: Unreviewed patch [was : PATCH: Protocol Warning]

[Jason Merrill]

This seems harmless to me, but I'm curious as to how a type with a
different TYPE_CONTEXT can have the same TYPE_MAIN_VARIANT.

Jason

Re: Unreviewed patch [was : PATCH: Protocol Warning]

[Devang Patel]

On Tuesday, August 20, 2002, at 09:45  AM, Jason Merrill wrote:

> This seems harmless to me, but I'm curious as to how a type with a
> different TYPE_CONTEXT can have the same TYPE_MAIN_VARIANT.

In Objective-C, a type can be qualified for a protocol. This permits the
compiler to test for a type based on conformance to a protocol.

Objective-C front end uses macro TYPE_PROTOCOL_LIST to keep list
of qualified protocols.

Here is relevant code snippet ...

objc-act.h:106:#define TYPE_PROTOCOL_LIST(TYPE) ((TYPE)->type.context)

objc-act.h:279 #define IS_PROTOCOL_QUALIFIED_ID(TYPE) \
objc-act.h:280   (IS_ID (TYPE) && TYPE_PROTOCOL_LIST (TYPE))

And from objc-act.c

     830   /* This clause creates a new pointer type that is qualified 
with
     831      the protocol specification...this info is used later to do 
more
     832      elaborate type checking.  */
     833
     834   if (protocols)
     835     {
     836       tree t, m = TYPE_MAIN_VARIANT (type);
     837
     838       t = copy_node (type);
     839       TYPE_BINFO (t) = make_tree_vec (2);
     840
     841       /* Add this type to the chain of variants of TYPE.  */
     842       TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
     843       TYPE_NEXT_VARIANT (m) = t;
     844
     845       /* Look up protocols...and install in lang specific list 
*/
     846       TYPE_PROTOCOL_LIST (t) = lookup_and_install_protocols 
(protocols);
     847
     848       /* This forces a new pointer type to be created later
     849          (in build_pointer_type)...so that the new template
     850          we just created will actually be used...what a hack!  
*/
     851       if (TYPE_POINTER_TO (t))
     852         TYPE_POINTER_TO (t) = NULL_TREE;
     853
     854       type = t;
     855     }


-Devang

Re: Unreviewed patch [was : PATCH: Protocol Warning]

[Jason Merrill]

On Tue, 20 Aug 2002 11:17:08 -0700, Devang Patel <dpatel@apple.com> wrote:

> On Tuesday, August 20, 2002, at 09:45  AM, Jason Merrill wrote:
>
>> This seems harmless to me, but I'm curious as to how a type with a
>> different TYPE_CONTEXT can have the same TYPE_MAIN_VARIANT.

> objc-act.h:106:#define TYPE_PROTOCOL_LIST(TYPE) ((TYPE)->type.context)

Ah, so it isn't TYPE_CONTEXT at all, ObjC has changed the meaning of that
field.  That seems dangerous; there are lots of things in the backend that
expect TYPE_CONTEXT to be the context of the type.  The debugging backends
in particular.  But it's been there since the dawn of time, so I guess your
patch is OK.

Jason

Fwd: Unreviewed patch [was : PATCH: Protocol Warning]

[Devang Patel]

This is still unreviewed. I would appreciate if somebody say something.
Thank you,

-Devang

Begin forwarded message:

> From: Devang Patel <dpatel@apple.com>
> Date: Wed Jul 31, 2002  6:04:42  PM US/Pacific
> To: gcc-patches@gcc.gnu.org
> Subject: Unreviewed patch [was : PATCH: Protocol Warning]
>
> Well, It passes check-g++ and check-gcc test.
>
> -Devang
>
> On Thursday, July 25, 2002, at 08:39  PM, Stan Shebs wrote:
>
>> Devang Patel wrote:
>>
>>>
>>> For the given test case, in Objective C, protocol 'qualified id'
>>> is incorrectly used for another 'id'. This happens when
>>> get_qualified_type () is tring to reuse existing TYPE.
>>>
>>> This simple patch adds one extra condition while deciding
>>> if a existing TYPE is suitable or not.
>>>
>>> Bootstrapped and passes testsuite check.
>>
>> From the ObjC point of view this is fine, but I'm not certain about
>> how this impacts the several other clients of get_qualified_type.
>> Could someone more knowledgeable look at this please?
>>
>> Stan
>>
>>>
>>> -Devang
>>>
>>> 07-24-2002 Devang Patel <dpatel@apple.com>
>>>         * tree.c (get_qualified_type): Add TYPE_CONTEXT check.
>>>
>>> testsuite:
>>>         * objc.dg/proto-hier-2.m: New test.
>>>
>>>
>>> Index: tree.c
>>> ===================================================================
>>> RCS file: /cvs/gcc/gcc/gcc/tree.c,v
>>> retrieving revision 1.268
>>> diff -c -3 -p -r1.268 tree.c
>>> *** tree.c      23 Jul 2002 21:58:56 -0000      1.268
>>> --- tree.c      25 Jul 2002 23:53:00 -0000
>>> *************** get_qualified_type (type, type_quals)
>>> *** 2866,2872 ****
>>>        like the one we need to have.  If so, use that existing one.  
>>> We must
>>>        preserve the TYPE_NAME, since there is code that depends on 
>>> this.  */
>>>     for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
>>> !     if (TYPE_QUALS (t) == type_quals && TYPE_NAME (t) == TYPE_NAME 
>>> (type))
>>>         return t;
>>>
>>>     return NULL_TREE;
>>> --- 2866,2873 ----
>>>        like the one we need to have.  If so, use that existing one.  
>>> We must
>>>        preserve the TYPE_NAME, since there is code that depends on 
>>> this.  */
>>>     for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
>>> !     if (TYPE_QUALS (t) == type_quals && TYPE_NAME (t) == TYPE_NAME 
>>> (type)
>>> !         && TYPE_CONTEXT (t) == TYPE_CONTEXT (type))
>>>         return t;
>>>
>>>     return NULL_TREE;
>>> Index: testsuite/objc.dg/proto-hier-2.m
>>> ===================================================================
>>> RCS file: testsuite/objc.dg/proto-hier-2.m
>>> diff -N testsuite/objc.dg/proto-hier-2.m
>>> *** /dev/null   1 Jan 1970 00:00:00 -0000
>>> --- testsuite/objc.dg/proto-hier-2.m    25 Jul 2002 23:53:00 -0000
>>> ***************
>>> *** 0 ****
>>> --- 1,49 ----
>>> + /* Test protocol warning.  */
>>> + /* Contributed by Devang Patel <dpatel@apple.com>.  */
>>> + /* { dg-do compile } */
>>> +
>>> + typedef struct objc_object { struct objc_class *class_pointer; } 
>>> *id;
>>> +
>>> + @protocol Bar
>>> + @end
>>> +
>>> + id <Bar> Foo_Bar () { }
>>> +
>>> + typedef struct
>>> + {
>>> +         int i;
>>> + } MyStruct;
>>> +
>>> + @interface Foo
>>> + {
>>> +   id _mainData;
>>> +   MyStruct *_anotherData;
>>> + }
>>> +
>>> + -(id) mainDataSource;
>>> + -(id) anotherDataSource;
>>> + -(id) my_method: (int) i;
>>> + @end
>>> +
>>> + @implementation Foo
>>> + -(id) anotherDataSource
>>> + {
>>> +         return (id)_anotherData;
>>> + }
>>> +
>>> + -(id) mainDataSource
>>> + {
>>> +         return _mainData;
>>> + }
>>> +
>>> + -(id) my_method: (int) i
>>> + {
>>> +   id one = [self anotherDataSource];
>>> +
>>> +   i = i - 1;
>>> +   // Do not issue warning about my_method not implemented by 
>>> protocol
>>> +   return [(one ? [self mainDataSource] : one) my_method:i];
>>> + }
>>> +
>>> + @end
>>> +
>>>
>>>
>>
>>
>>
>
> -Devang
>
>

-Devang