In gcc/objc/: 2010-11-25 Nicola Pero <nicola.pero@meta-innovation.com>

In gcc/objc/:
2010-11-25  Nicola Pero  <nicola.pero@meta-innovation.com>

	* objc-act.c (objc_build_struct): Install TYPE_OBJC_INTERFACE
	after finish_struct, not before, otherwise it may be wiped out by
	it.  This fixes spurious warnings when a class has more than 15
	instance variables.

In gcc/testsuite/:
2010-11-25  Nicola Pero  <nicola.pero@meta-innovation.com>

	* objc.dg/ivar-problem-1.m: New.
	* obj-c++.dg/ivar-problem-1.mm: New.

From-SVN: r167151
This commit is contained in:
Nicola Pero 2010-11-25 19:50:13 +00:00 committed by Nicola Pero
parent 92724e1d70
commit 24e1ee3219
5 changed files with 160 additions and 8 deletions

View File

@ -1,3 +1,10 @@
2010-11-25 Nicola Pero <nicola.pero@meta-innovation.com>
* objc-act.c (objc_build_struct): Install TYPE_OBJC_INTERFACE
after finish_struct, not before, otherwise it may be wiped out by
it. This fixes spurious warnings when a class has more than 15
instance variables.
2010-11-23 Nicola Pero <nicola.pero@meta-innovation.com>
PR objc/24358

View File

@ -2137,10 +2137,15 @@ objc_build_struct (tree klass, tree fields, tree super_name)
fields = base;
}
/* NB: Calling finish_struct() may cause type TYPE_LANG_SPECIFIC fields
in all variants of this RECORD_TYPE to be clobbered, but it is therein
that we store protocol conformance info (e.g., 'NSObject <MyProtocol>').
Hence, we must squirrel away the ObjC-specific information before calling
/* NB: Calling finish_struct() may cause type TYPE_LANG_SPECIFIC
fields in all variants of this RECORD_TYPE to be clobbered (this
is because the C frontend stores a sorted version of the list of
fields in lang_type if it deems appropriate, and will update and
propagate that list to all variants ignoring the fact that we use
lang_type for something else and that such propagation will wipe
the objc_info away), but it is therein that we store protocol
conformance info (e.g., 'NSObject <MyProtocol>'). Hence, we must
squirrel away the ObjC-specific information before calling
finish_struct(), and then reinstate it afterwards. */
for (t = TYPE_NEXT_VARIANT (s); t; t = TYPE_NEXT_VARIANT (t))
@ -2153,12 +2158,16 @@ objc_build_struct (tree klass, tree fields, tree super_name)
VEC_safe_push (tree, heap, objc_info, TYPE_OBJC_INFO (t));
}
/* Point the struct at its related Objective-C class. */
INIT_TYPE_OBJC_INFO (s);
TYPE_OBJC_INTERFACE (s) = klass;
s = objc_finish_struct (s, fields);
/* Point the struct at its related Objective-C class. We do this
after calling finish_struct() because otherwise finish_struct()
would wipe TYPE_OBJC_INTERFACE() out. */
if (!TYPE_HAS_OBJC_INFO (s))
INIT_TYPE_OBJC_INFO (s);
TYPE_OBJC_INTERFACE (s) = klass;
for (i = 0, t = TYPE_NEXT_VARIANT (s); t; t = TYPE_NEXT_VARIANT (t), i++)
{
TYPE_OBJC_INFO (t) = VEC_index (tree, objc_info, i);

View File

@ -1,3 +1,8 @@
2010-11-25 Nicola Pero <nicola.pero@meta-innovation.com>
* objc.dg/ivar-problem-1.m: New.
* obj-c++.dg/ivar-problem-1.mm: New.
2010-11-25 Jakub Jelinek <jakub@redhat.com>
PR middle-end/46637

View File

@ -0,0 +1,66 @@
/* Contributed by Nicola Pero <nicola.pero@meta-innovation.com>, November 2010. */
/* { dg-do compile } */
/* This test checks what happens if there are 16 instance variables.
In that case, the class was not created correctly. In this testcase,
we have two classes, one with 15 variables and one with 16. Older
GCCs would generate a bogus warning for the second class but not
for the first one. This only happened for ObjC, but it's good to
test ObjC++ as well. */
#include <stdlib.h>
#include <objc/objc.h>
@interface MyRootClass1
{
Class isa;
int v2;
int v3;
int v4;
int v5;
int v6;
int v7;
int v8;
int v9;
int v10;
int v11;
int v12;
int v13;
int v14;
int v15;
}
- (id) init;
@end
@implementation MyRootClass1
- (id) init { return self; }
@end
@interface MyRootClass2
{
Class isa;
int v2;
int v3;
int v4;
int v5;
int v6;
int v7;
int v8;
int v9;
int v10;
int v11;
int v12;
int v13;
int v14;
int v15;
/* Adding the 16th variable used to cause bogus warnings to be
generated. */
int v16;
}
- (id) init;
@end
@implementation MyRootClass2
- (id) init { return self; } /* This should not generate a bogus warning. */
@end

View File

@ -0,0 +1,65 @@
/* Contributed by Nicola Pero <nicola.pero@meta-innovation.com>, November 2010. */
/* { dg-do compile } */
/* This test checks what happens if there are 16 instance variables.
In that case, the class was not created correctly. In this testcase,
we have two classes, one with 15 variables and one with 16. Older
GCCs would generate a bogus warning for the second class but not
for the first one. */
#include <stdlib.h>
#include <objc/objc.h>
@interface MyRootClass1
{
Class isa;
int v2;
int v3;
int v4;
int v5;
int v6;
int v7;
int v8;
int v9;
int v10;
int v11;
int v12;
int v13;
int v14;
int v15;
}
- (id) init;
@end
@implementation MyRootClass1
- (id) init { return self; }
@end
@interface MyRootClass2
{
Class isa;
int v2;
int v3;
int v4;
int v5;
int v6;
int v7;
int v8;
int v9;
int v10;
int v11;
int v12;
int v13;
int v14;
int v15;
/* Adding the 16th variable used to cause bogus warnings to be
generated. */
int v16;
}
- (id) init;
@end
@implementation MyRootClass2
- (id) init { return self; } /* This should not generate a bogus warning. */
@end