[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-10-18 11:31:49 UTC --- Author: nicola Date: Tue Oct 18 11:31:45 2011 New Revision: 180132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180132 Log: In gcc/objc/: 2011-10-18 Mikael Pettersson mi...@it.uu.se PR objc/50743 * objc-act.c (check_duplicates): Cast TREE_VEC_LENGTH result to size_t to avoid signed/unsigned comparison. (insert_method_into_method_map): Likewise. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c
[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-10-18 11:39:55 UTC --- Can you confirm that trunk is now OK ? Thanks
[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-16 Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-16 11:03:59 UTC --- Thanks for reporting this! The patch looks good to me (but I can't approve it). Alternatively, I suppose, the iterating variable itself could be declared as int. Do you want to submit the patch to gcc-patc...@gnu.org ? Thanks
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-10-15 08:04:39 UTC --- Author: nicola Date: Sat Oct 15 08:04:33 2011 New Revision: 180023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180023 Log: In gcc/cp/: 2011-10-15 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-06-06 Nicola Pero nicola.p...@meta-innovation.com, PR obj-c++/48275 * parser.c (cp_parser_objc_at_property_declaration): Allow setter and getter names to use all the allowed method names. In gcc/testsuite/: 2011-10-15 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-06-06 Nicola Pero nicola.p...@meta-innovation.com PR objc-++/48275 * obj-c++.dg/property/cxx-property-1.mm: New. * obj-c++.dg/property/cxx-property-2.mm: New. Added: branches/gcc-4_6-branch/gcc/testsuite/obj-c++.dg/property/cxx-property-1.mm branches/gcc-4_6-branch/gcc/testsuite/obj-c++.dg/property/cxx-property-2.mm Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/parser.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-10-14 17:10:21 UTC --- Author: nicola Date: Fri Oct 14 17:10:14 2011 New Revision: 179996 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179996 Log: In libobjc/: 2011-10-14 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * class.c (__objc_update_classes_with_methods): Iterate over meta classes as well as normal classes when refreshing the method implementations. This fixes replacing class methods. Modified: branches/gcc-4_6-branch/libobjc/ChangeLog branches/gcc-4_6-branch/libobjc/class.c
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-10-14 17:19:15 UTC --- Author: nicola Date: Fri Oct 14 17:19:07 2011 New Revision: 179997 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179997 Log: In libobjc/: 2011-10-14 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-10-09 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49883 * init.c (__objc_exec_class): Work around a bug in clang's code generation. Clang sets the class-info field to values different from 0x1 or 0x2 (the only allowed values in the traditional GNU Objective-C runtime ABI) to store some additional information, but this breaks backwards compatibility. Wipe out all the bits in the fields other than the first two upon loading a class. Modified: branches/gcc-4_6-branch/libobjc/ChangeLog branches/gcc-4_6-branch/libobjc/init.c
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:29:54 UTC --- Author: nicola Date: Sun Oct 9 10:29:50 2011 New Revision: 179721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179721 Log: In libobjc/: 2011-10-09 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49883 * init.c (__objc_exec_class): Work around a bug in clang's code generation. Clang sets the class-info field to values different from 0x1 or 0x2 (the only allowed values in the traditional GNU Objective-C runtime ABI) to store some additional information, but this breaks backwards compatibility. Wipe out all the bits in the fields other than the first two upon loading a class. 2011-10-09 Nicola Pero nicola.p...@meta-innovation.com * class.c (objc_lookup_class): Added back for compatibility with clang which seems to emit calls to it. Modified: trunk/libobjc/ChangeLog trunk/libobjc/class.c trunk/libobjc/init.c
[Bug libobjc/49883] clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:31:04 UTC --- Fixed in trunk. Thanks
[Bug libobjc/50003] -[Protocol respondsTo:] does not work with Clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50003
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:47:11
UTC ---
With GCC trunk (pre-4.7.0), the code reported can't be used because it's using
the Traditional Objective-C runtime API and not the Modern one.
The right implementation with the Modern API is:
+ (BOOL)conformsToProtocol: (Protocol*)protocol
{
Class c;
for (c = self; c != Nil; c = class_getSuperclass (c))
if (class_conformsToProtocol (c, protocol))
return YES;
return NO;
}
I tested this with both GCC and clang, and it seems to work fine with both.
Thanks
[Bug libobjc/50368] Implicit, precision losing cast in objc/objc-api.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50368 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nicola at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 10:50:47 UTC --- Florian, thanks a lot for your report. You are right that there is a loss-precision cast in there. :-) But the function class_get_version() was part of the Traditional API, which was deprecated in GCC 4.6.1 and has been removed in trunk (ie, GCC 4.7.0). So, the function class_get_version() (and the entire file objc/objc-api.h) will no longer exist in GCC 4.7.0, which implicitly fixes your problem. :-) Thanks again!
[Bug objc++/48394] ObjC exceptions cannot be caught in ObjC++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48394 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 23:11:09 UTC --- Yes, as far as I can see this is basically a duplicate of objc++/23616. The problem is that Objective-C exceptions in ObjC++ simply don't work due to a basic problem in the implementation. :-( Thanks *** This bug has been marked as a duplicate of bug 23616 ***
[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||js-gcc at webkeks dot org --- Comment #14 from Nicola Pero nicola at gcc dot gnu.org 2011-10-09 23:11:09 UTC --- *** Bug 48394 has been marked as a duplicate of this bug. ***
[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-08 17:52:11 UTC --- Author: nicola Date: Sat Oct 8 17:52:06 2011 New Revision: 179711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179711 Log: In libobjc/: 2011-10-08 Richard Frith-Macdonald r...@gnu.org Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50428 * sendmsg.c (__objc_send_initialize): If a class does not have an +initialize method, search for an +initialize method in the superclass and in the ancestor classes and execute the first one that is found. This makes the GNU runtime behave in the same way as the Apple/NeXT runtime with respect to +initialize methods and subclassing. In gcc/: 2011-10-08 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50428 * doc/objc.texi (Garbage Collection): Updated example to protect +initialize against execution in subclasses. In gcc/testsuite/: 2011-10-08 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50428 * objc/execute/initialize-1.m: New test. Added: trunk/gcc/testsuite/objc/execute/initialize-1.m Modified: trunk/gcc/ChangeLog trunk/gcc/doc/objc.texi trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/sendmsg.c
[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-10-08 17:56:09 UTC --- Implemented in trunk. The change will appear in 4.7.0. Thanks
[Bug libobjc/50428] New: Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 Bug #: 50428 Summary: Consider changing semantics of +initialize so that it is inherited Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: nic...@gcc.gnu.org One of the remaining differences between the GNU Objective-C runtime and the Apple one is that +initialize methods are inherited in the Apple runtime but not in the GNU one. To reduce differences, we could change the GNU runtime to inherit them too. This is a change in behaviour and should be clearly advertised in the release notes. Thanks
[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-16 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-09-16 08:04:13 UTC --- We should also document +initialize in the GCC Manual, no matter if we keep the existing semantics or change them. Thanks
[Bug libobjc/50002] New: class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002
Summary: class_replaceMethod does not work on class methods
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Reported by Jonathan Schleifer --
#include stdio.h
#include assert.h
#import objc/Object.h
#import objc/runtime.h
id
alloc(Class self, SEL _cmd)
{
puts(Foo!);
return nil;
}
int
main()
{
Method method = class_getClassMethod([Object class], @selector(alloc));
assert(method != NULL);
/* INCOMPATIBLE to Apple! class_pointer should be isa!! */
class_replaceMethod([Object class]-class_pointer, @selector(alloc),
(IMP)alloc, method_getTypeEncoding(method));
[Object alloc];
return 0;
}
If you change Object to NSObject and class_pointer to isa, it works on OS X.
Thanks
[Bug libobjc/50003] New: -[Protocol respondsTo:] does not work with Clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50003
Summary: -[Protocol respondsTo:] does not work with Clang
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Jonathan Schleifer reports --
Hi!
When using -[Protocol respondsTo:] in the new GNU runtime, it seems to return
NO, even if the object conforms to the protocol. The code I use is this:
+ (BOOL)conformsToProtocol: (Protocol*)protocol
{
Class c;
struct objc_protocol_list *pl;
size_t i;
for (c = self; c != Nil; c = class_get_super_class(c))
for (pl = c-protocols; pl != NULL; pl = pl-next)
for (i = 0; i pl-count; i++)
if ([pl-list[i] conformsTo: protocol])
return YES;
return NO;
}
It works when just using gcc 4.6.1, and it seems to work with older versions of
the GNU runtime.
Thanks
PS: For clarity, Jonathan uses the GCC Objective-C runtime with other
Objective-C compilers as well, such as clang.
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 09:49:33 UTC --- Author: nicola Date: Sat Aug 6 09:49:30 2011 New Revision: 177505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177505 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * class.c (class_getSuperclass): Return the superclass if the class is in construction. * objc/runtime.h (class_getSuperclass): Updated documentation. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * objc.dg/gnu-api-2-class.m (main): Test class_getSuperclass() with classes that are in construction. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c trunk/libobjc/objc/runtime.h
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:20:13 UTC --- Author: nicola Date: Sat Aug 6 14:20:09 2011 New Revision: 177510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177510 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * class.c (__objc_update_classes_with_methods): Iterate over meta classes as well as normal classes when refreshing the method implementations. This fixes replacing class methods. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com * class.c (class_getSuperclass): Fixed to work with meta classes still in construction too. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * objc.dg/gnu-api-2-class.m: Updated comments. * obj-c++.dg/gnu-api-2-class.mm: Likewise. * objc.dg/gnu-api-2-class-meta.m: New test. * obj-c++.dg/gnu-api-2-class-meta.mm: Likewise. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * obj-c++.dg/gnu-api-2-class.mm (main): Test class_getSuperclass() with classes that are in construction. Added: trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class-meta.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class-meta.m Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:20:13 UTC --- Author: nicola Date: Sat Aug 6 14:20:09 2011 New Revision: 177510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177510 Log: In libobjc/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * class.c (__objc_update_classes_with_methods): Iterate over meta classes as well as normal classes when refreshing the method implementations. This fixes replacing class methods. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com * class.c (class_getSuperclass): Fixed to work with meta classes still in construction too. In gcc/testsuite/: 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/50002 * objc.dg/gnu-api-2-class.m: Updated comments. * obj-c++.dg/gnu-api-2-class.mm: Likewise. * objc.dg/gnu-api-2-class-meta.m: New test. * obj-c++.dg/gnu-api-2-class-meta.mm: Likewise. 2011-08-06 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/49882 * obj-c++.dg/gnu-api-2-class.mm (main): Test class_getSuperclass() with classes that are in construction. Added: trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class-meta.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class-meta.m Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/libobjc/ChangeLog trunk/libobjc/class.c
[Bug libobjc/49882] class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:21:29 UTC --- Confirmed, then fixed in trunk (which will be 4.7.x). Thanks
[Bug libobjc/50002] class_replaceMethod does not work on class methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50002 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-08-06 14:22:16 UTC --- Confirmed, and fixed in trunk (will go into 4.7). Thanks
[Bug libobjc/49882] New: class_getSuperClass() returns nil on a newly allocated, but not registered, class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49882 Summary: class_getSuperClass() returns nil on a newly allocated, but not registered, class Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: nic...@gcc.gnu.org From Ludovic Marcotte ludo...@sophos.ca -- There's a bug with the gcc 4.6 runtime since objc_getSuperClass() on a newly allocated - but not registered - class returns nil. Unfortunately, this is actually a documented behaviour of the GCC 4.6 runtime, so we can't really change it in GCC 4.6.x. But if this is how the Apple runtime behaves, in 4.7.0 we should change our runtime (and the corresponding documentation) to match. Thanks
[Bug libobjc/49883] New: clang + gcc 4.6 runtime = broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883
Summary: clang + gcc 4.6 runtime = broken
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
From Jonathan Schleifer --
the following code does not work when using Clang with the runtime of gcc 4.6:
#include stdio.h
#include stdlib.h
#import objc/runtime.h
@interface A
{
Class isa;
}
+ alloc;
+ (Class)class;
@end
@interface B: A
@end
@implementation A
+ alloc
{
A *instance = malloc(class_getInstanceSize(self));
instance-isa = self;
return instance;
}
+ (Class)class
{
return self;
}
- (BOOL)isKindOfClass: (Class)class
{
Class iter;
for (iter = isa; iter != Nil; iter = class_getSuperclass(iter))
if (iter == class)
return YES;
return NO;
}
@end
@implementation B
@end
int
main()
{
B *b = [B alloc];
printf(%d\n, [b isKindOfClass: [B class]]);
printf(%d\n, [b isKindOfClass: [A class]]);
return 0;
}
---
Upon further inspection, it seems likely that clang's Objective-C compiler,
when compiling for the GNU runtime, is abusing some fields in the ABI.
In particular, it seems that clang is no longer setting the class-info field
to 1 or 2, but to something like 17 or 18. This is in my view a bug in clang,
but I'm also aware that some users really do need this to be sorted out and
backported to 4.6.x.
It should be possible to work around the problem by simply detecting the 17
or 18 when loading the class, and converting it to a 1 or 2. I also produced a
preliminary (untested) patch to work around this problem --
Index: init.c
===
--- init.c(revision 176090)
+++ init.c(working copy)
@@ -643,6 +643,14 @@
assert (CLS_ISMETA (class-class_pointer));
DEBUG_PRINTF ( installing class '%s'\n, class-name);
+ /* Clang may set flags other than _CLS_CLASS and _CLS_META even
+ when compiling for the traditional ABI (version 8), confusing
+ our runtime. Try to wipe these flags out. */
+ if (CLS_ISCLASS (class))
+__CLS_INFO (class) = _CLS_CLASS;
+ else
+__CLS_INFO (class) = _CLS_META;
+
/* Initialize the subclass list to be NULL. In some cases it
isn't and this crashes the program. */
class-subclass_list = NULL;
but was told that it doesn't work, so someone will now need to install clang
and figure out what is actually happening.
Thanks
[Bug testsuite/49432] [4.7 Regression] FAIL: obj-c++.dg/invalid-type-1.mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49432 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-06-16 22:03:41 UTC --- Looks good ... you should submit the patch to gcc-patches ;-) Thanks
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #23 from Nicola Pero nicola at gcc dot gnu.org 2011-06-14 18:26:40 UTC --- Yes, in a strict sense this bug could be closed ... because objc_msg_sendv() no longer exists in the GNU Objective-C runtime. So if the bug is about it not working on some platforms, it can certainly be closed. ;-) Forwarding in libobjc still uses __builtin_apply(), so the problem, in a wider sense, still exists. But that forwarding is not used by any user of libobjc as far as I know (they all have their own libffi-based implementation of forwarding that are used through the forwarding hooks that libobjc has) and I'm planning on entirely removing it for 4.7.0 - it's unused (the forwarding hooks override any implementation in libobjc), and it often doesn't work. I also have some other plans for a new forwarding infrastructure, that may or may not happen for 4.7.0. Summarizing, I would close the bug, or leave it open but just to remind me/us to: * remove the existing forwarding code from libobjc; * remove the forward-1.m testcase; * add new testcases for the libobjc forwarding hooks. As these are the official ways to use forwarding (and the only ones available), we should have testcases. Let me know if you have any comments. Thanks
[Bug objc/49301] Forward declaration of classes broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49301
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 15:14:24
UTC ---
@class is used to tell the compiler the class exists, but that its not (yet)
available. Eg: class B uses class A, but class A uses class B too, creating a
recursive import, and thus goes wrong.
Yes, that's correct. Notice that there is no messaging involved in this
scenario. ;-)
An example would look like:
@class B;
@interface A
- (B *) giveMeB;
@end
@interface B
- (A *) giveMeA;
@end
without '@class B', the example doesn't compile because a method in
@interface A return B *, which isn't known yet, and moving @interface B
before @interface A doesn't work because @interface B itself returns
A *.
This is mostly a concern for header files.
#import objc/objc.h
#import objc/Object.h
@class myClass;
int main()
{
myClass *obj = [myClass new];
}
@interface myClass : Object
@end
@implementation myClass
@end
This example is completely different. You are messaging 'myClass' which is
forward-declared, and the compiler can't determine if the class responds to
+new or not. ;-)
So, there is a problem with determining the correct method prototype, a
problem which wasn't obvious before because the compiler wasn't warning about
the problem ;-)
You can trivially fix it by moving @interface myClass before int main().
Note that both the recent Apple GCC and Apple clang emit a similar warning.
For example, compiling your code with clang produces:
example.m:8:19: warning: receiver 'myClass' is a forward class and
corresponding @interface may not exist
myClass *obj = [myClass new];
^
example.m:8:18: warning: method '+new' not found (return type defaults to
'id')
myClass *obj = [myClass new];
^
example.m:8:12: warning: unused variable 'obj' [-Wunused-variable]
myClass *obj = [myClass new];
^
3 warnings generated.
So this warning is not specific to GCC. ;-)
By the way, the warning is useful, because when messaging a Class only declared
with a @class, the compiler is blind as to what messages it can accept, and
won't do any checks on method invocations. :-(
Thanks
[Bug objc/49301] Forward declaration of classes broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49301
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
CC||nicola at gcc dot gnu.org
--- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 15:51:27
UTC ---
But could we turn it off with some flag?
Not at the moment. We could add a flag to turn it off if there are enough
important examples.
And also, in my example, the interface is just BELOW! I think GCC should first
look further… just a thought.
:-)
So in programming it must be like this:
The header file has a @class, so the class can be used for variables and
method arguments.
Yes, header files can use @class to refer to classes defined in other headers
and prevent recursive class definitions. Eg, the header B.h could be:
@class A;
@interface B
- (A *)giveMeA;
@end
and the header A.h could be:
@class B;
@interface A
- (B *)giveMeB;
@end
the two headers are now independent and you can include them independently
with no recursion.
The method file should have the actual import of the interface, so the
messages are known, and no recursive import occurs?
Yes, the implementation generally should include full @interfaces for all
the classes that are involved in messaging ... so that the compiler can do
the checks. In the example above, in A.m you would do
#import A.h
#import B.h
@implementation A
- (B *) giveMeB
{
...
}
@end
and similarly in the implementation of B. No recursive @interface definitions
would occur, and the actual Objective-C code (... in the example) has the
full
@interfaces for all the classes and can do full type-checking. :-)
You could also a general header that #imports both A.h and B.h, and #import
that one instead.
Thanks
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 22:09:51 UTC --- Author: nicola Date: Mon Jun 6 22:09:47 2011 New Revision: 174726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174726 Log: In gcc/cp/: 2011-06-06 Nicola Pero nicola.p...@meta-innovation.com, PR obj-c++/48275 * parser.c (cp_parser_objc_at_property_declaration): Allow setter and getter names to use all the allowed method names. In gcc/testsuite/: 2011-06-06 Nicola Pero nicola.p...@meta-innovation.com PR objc-++/48275 * obj-c++.dg/property/cxx-property-1.mm: New. * obj-c++.dg/property/cxx-property-2.mm: New. Added: trunk/gcc/testsuite/obj-c++.dg/property/cxx-property-1.mm trunk/gcc/testsuite/obj-c++.dg/property/cxx-property-2.mm Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.0 Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 22:49:07 UTC --- Resolved in trunk. Thanks
[Bug objc/49301] Forward declaration of classes broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49301 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 23:23:12 UTC --- Jos, thanks for your feedback. Thanks
[Bug testsuite/49287] [4.7 Regression] FAIL: obj(c|-c++).dg/gnu-api-2-(class|objc).(m|mm) -fnext-runtime (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49287 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.05 13:07:58 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-06-05 13:07:58 UTC --- Thanks Dominique I submitted a patch to fix this. Thanks
[Bug testsuite/49287] [4.7 Regression] FAIL: obj(c|-c++).dg/gnu-api-2-(class|objc).(m|mm) -fnext-runtime (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49287 --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-06-05 17:37:09 UTC --- Author: nicola Date: Sun Jun 5 17:37:06 2011 New Revision: 174657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174657 Log: In gcc/objc/: 2011-06-05 Nicola Pero nicola.p...@meta-innovation.com * objc-act.c (receiver_is_class_object): Expanded comment. (objc_finish_message_expr): Likewise. In gcc/testsuite/: 2011-06-05 Nicola Pero nicola.p...@meta-innovation.com PR testsuite/49287 * objc.dg/gnu-api-2-class.m: Updated testcase silencing compiler warning. * objc.dg/gnu-api-2-objc.m: Likewise. * obj-c++.dg/gnu-api-2-class.mm: Likewise * obj-c++.dg/gnu-api-2-objc.mm: Likewise. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-class.mm trunk/gcc/testsuite/obj-c++.dg/gnu-api-2-objc.mm trunk/gcc/testsuite/objc.dg/gnu-api-2-class.m trunk/gcc/testsuite/objc.dg/gnu-api-2-objc.m
[Bug testsuite/49287] [4.7 Regression] FAIL: obj(c|-c++).dg/gnu-api-2-(class|objc).(m|mm) -fnext-runtime (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49287 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.0 Resolution||FIXED --- Comment #6 from Nicola Pero nicola at gcc dot gnu.org 2011-06-05 19:18:11 UTC --- Fixed in trunk. Thanks
[Bug objc/48539] Missing warning when messaging a forward-declared class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48539 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-06-02 18:54:34 UTC --- Author: nicola Date: Thu Jun 2 18:54:32 2011 New Revision: 174575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174575 Log: In gcc/objc/: 2011-06-02 Nicola Pero nicola.p...@meta-innovation.com PR objc/48539 * objc-act.c (objc_finish_message_expr): Warn if messaging a class that was only declared using @class without an @interface. Warn if messaging an instance of a class that was only declared using @class without an @interface, unless the receiver was also typed with a protocol list. In gcc/testsuite/: 2011-06-02 Nicola Pero nicola.p...@meta-innovation.com PR objc/48539 * objc.dg/method-5.m: Updated. * objc.dg/method-19.m: Updated. * objc.dg/method-lookup-1.m: New. * obj-c++.dg/method-6.mm: Updated. * obj-c++.dg/method-7.mm: Updated. * obj-c++.dg/method-lookup-1.mm: New. Added: trunk/gcc/testsuite/obj-c++.dg/method-lookup-1.mm trunk/gcc/testsuite/objc.dg/method-lookup-1.m Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/method-6.mm trunk/gcc/testsuite/obj-c++.dg/method-7.mm trunk/gcc/testsuite/objc.dg/method-19.m trunk/gcc/testsuite/objc.dg/method-5.m
[Bug objc/48539] Missing warning when messaging a forward-declared class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48539 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.0 Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-06-02 18:58:57 UTC --- Resolved on trunk. Thanks
[Bug objc/47077] ICE on invalid code (method implementation outside of implementation context)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47077 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.01 08:40:25 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-06-01 08:40:25 UTC --- Yes, confirmed. Thanks
[Bug c++/49221] [4.7 Regression] Several ICEs in the obj-c++ test suite after revision 174307
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49221
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.01 09:28:00
CC||nicola at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-06-01 09:28:00
UTC ---
Yes, this is confirmed. Here is what I see --
=== obj-c++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/nicola/GCC/trunk2/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/attributes/attributes.exp ...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/dg.exp ...
FAIL: obj-c++.dg/exceptions-3.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/exceptions-3.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/exceptions-4.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/exceptions-4.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/exceptions-5.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/exceptions-5.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/fobjc-exceptions-1.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/fobjc-exceptions-1.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/fobjc-exceptions-2.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/fobjc-exceptions-2.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/fobjc-exceptions-3.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/fobjc-exceptions-3.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/try-catch-4.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/try-catch-4.mm -fgnu-runtime (test for excess errors)
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/lto/lto.exp ...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/property/property.exp
...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/strings/strings.exp
...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/tls/tls.exp ...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/torture/dg-torture.exp
...
Running
/home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/torture/strings/strings.exp
...
Running /home/nicola/GCC/trunk2/gcc/testsuite/obj-c++.dg/torture/tls/tls.exp
...
=== obj-c++ Summary ===
# of expected passes1422
# of unexpected failures16
# of expected failures 2
# of unsupported tests 86
/home/nicola/GCC/build-trunk2-full-parallel/gcc/testsuite/obj-c++/../../g++
version 4.7.0 20110601 (experimental) (GCC)
make[1]: [check-obj-c++] Error 1 (ignored)
make[1]: Leaving directory `/home/nicola/GCC/build-trunk2-full-parallel/gcc'
For the record, they are due to the compiler crashing in add_stmt(). Here is a
stack trace of the compiler just before crashing --
Breakpoint 1, add_stmt (t=0xb7d9ebb8) at ../../trunk2/gcc/cp/semantics.c:381
381 {
(gdb) i stack
#0 add_stmt (t=0xb7d9ebb8) at ../../trunk2/gcc/cp/semantics.c:381
#1 0x08145b40 in cp_finish_decl (decl=0xb7da94e0, init=0x0,
init_const_expr_p=0 '\000', asmspec_tree=0x0, flags=0) at
../../trunk2/gcc/cp/decl.c:6194
#2 0x080de1bf in finish_var_decl (var=0xb7da94e0, initializer=0xb7da4300) at
../../trunk2/gcc/objc/objc-runtime-shared-support.c:144
#3 0x080e20a5 in objc_eh_runtime_type (type=0xb7d95780) at
../../trunk2/gcc/objc/objc-gnu-runtime-abi-01.c:2190
#4 0x0844c0c9 in add_type_for_runtime (type=0xb7d95780) at
../../trunk2/gcc/except.c:660
#5 add_type_for_runtime (type=0xb7d95780) at ../../trunk2/gcc/except.c:648
#6 0x0844c20d in gen_eh_region_catch (t=0xb7da8690, type_or_list=0xb7d95780)
at ../../trunk2/gcc/except.c:375
#7 0x086e3972 in lower_catch (state=0xbfffe634, seq=Unhandled dwarf expression
opcode 0xf3
) at ../../trunk2/gcc/tree-eh.c:1680
#8 lower_eh_constructs_2 (state=0xbfffe634, seq=Unhandled dwarf expression
opcode 0xf3
) at ../../trunk2/gcc/tree-eh.c:1958
#9 lower_eh_constructs_1 (state=0xbfffe634, seq=Unhandled dwarf expression
opcode 0xf3
) at ../../trunk2/gcc/tree-eh.c:1996
#10 0x086e3621 in lower_try_finally (state=0xbfffe6b4, seq=Unhandled dwarf
expression opcode 0xf3
) at ../../trunk2/gcc/tree-eh.c:1566
#11 lower_eh_constructs_2 (state=0xbfffe6b4, seq=Unhandled dwarf expression
opcode 0xf3
) at ../../trunk2/gcc/tree-eh.c:1945
#12 lower_eh_constructs_1 (state=0xbfffe6b4, seq=Unhandled dwarf
[Bug libobjc/49166] [4.7 Regression] Many objc failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49166 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-05-26 10:14:13 UTC --- Yes. I have a Linux/x86-64 machine, and the patch I committed fixes the regressions on there too. :-) The reason is that, due to the missing function declaration, the compiler would assume the return value is 'int', while it's 'Class' (a pointer). They differ in size on 64-bit and that would cause the failures. Thanks
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 --- Comment #7 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 09:08:00 UTC --- Author: nicola Date: Wed May 25 09:07:57 2011 New Revision: 174176 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174176 Log: In libobjc/: 2011-05-25 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/48177 * selector.c (__sel_register_typed_name): Use sel_types_match() instead of strcmp() to compare selector types (Suggestion by Richard Frith-Macdonald r...@gnu.org). In gcc/testsuite/: 2011-05-25 Nicola Pero nicola.p...@meta-innovation.com Backport from mainline 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/48177 * objc.dg/pr48177.m: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/objc.dg/pr48177.m Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/libobjc/ChangeLog branches/gcc-4_6-branch/libobjc/selector.c
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 09:13:32 UTC --- Applied to the 4.6 branch as well. 4.6.1 will include this fix. Thanks
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037 --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 18:54:43 UTC --- Author: nicola Date: Wed May 25 18:54:40 2011 New Revision: 174221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174221 Log: In libobjc/: 2011-05-25 Richard Frith-Macdonald r...@gnu.org David Ayers ay...@fsfe.org PR libobjc/38037 * sendmsg.c: Include objc/hash.h. (get_implementation): New function, mostly with code from get_imp updated to support the new +initialize dispatch table logic. (get_imp): Use get_implementation. (__objc_responds_to): Updated to support the new +initialize dispatch table logic. (class_respondsToSelector): Likewise. (objc_msg_lookup): Use get_implementation. (__objc_init_install_dtable): Removed. (__objc_install_methods_in_dtable): Updated arguments. (__objc_install_dispatch_table_for_class): Renamed to __objc_install_dtable_for_class and updated to support the new +initialize dispatch table logic. (__objc_update_dispatch_table_for_class): Updated to support the new +initialize dispatch table logic. (__objc_forward): Call get_implementation instead of get_imp. (prepared_dtable_table): New. (__objc_prepare_dtable_for_class): New. (__objc_prepared_dtable_for_class): New. (__objc_get_prepared_imp): New. (__objc_install_prepared_dtable_for_class): New. Modified: trunk/libobjc/ChangeLog trunk/libobjc/sendmsg.c
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||nicola at gcc dot gnu.org Resolution||FIXED --- Comment #10 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 18:56:19 UTC --- I applied the patch to trunk. Thanks a lot! :-)
[Bug objc/48187] infinite errors with misplaced [ in @interface definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48187 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 18:58:45 UTC --- Patch applied to trunk. Thanks
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037 --- Comment #7 from Nicola Pero nicola at gcc dot gnu.org 2011-05-25 20:32:46 UTC --- Apologies. You are right; I committed a fix for libobjc/38307. ;-) Thanks
[Bug objc/47682] unused-but-set-variabled warning when using fast enumeration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47682 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-05-24 11:56:54 UTC --- 3 months have passed with no reply; assuming resolved. It certainly works for me. :-) Thanks
[Bug objc/48187] infinite errors with misplaced [ in @interface definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48187 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-05-24 17:45:59 UTC --- I have a patch ready to fix this -- http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01735.html Thanks
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 --- Comment #6 from Nicola Pero nicola at gcc dot gnu.org 2011-05-24 21:43:47 UTC --- I applied the fix. Waiting for approval to apply it for the 4.6 branch as well so that it gets into 4.6.1. :-) Thanks
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-05-24 21:39:29 UTC --- Author: nicola Date: Tue May 24 21:39:24 2011 New Revision: 174143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174143 Log: In libobjc/: 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/48177 * selector.c (__sel_register_typed_name): Use sel_types_match() instead of strcmp() to compare selector types (Suggestion by Richard Frith-Macdonald r...@gnu.org). In gcc/testsuite/: 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/48177 * objc.dg/pr48177.m: New testcase. Added: trunk/gcc/testsuite/objc.dg/pr48177.m Modified: trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/selector.c
[Bug objc/48187] infinite errors with misplaced [ in @interface definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48187 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-05-24 21:29:38 UTC --- Author: nicola Date: Tue May 24 21:29:35 2011 New Revision: 174142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174142 Log: In gcc/: 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR objc/48187 * c-parser.c (c_parser_objc_class_instance_variables): More robust parsing of syntax error in ObjC instance variable lists. In particular, avoid an infinite loop if there is a stray ']'. Updated error message. In gcc/cp/: 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com, * parser.c (cp_parser_objc_class_ivars): Deal gracefully with a syntax error in declaring an ObjC instance variable. In gcc/testsuite/: 2011-05-24 Nicola Pero nicola.p...@meta-innovation.com PR objc/48187 * objc.dg/pr48187.m: New testcase. * obj-c++.dg/pr48187.mm: New testcase. * objc.dg/ivar-extra-semicolon.m: New testcase. Added: trunk/gcc/testsuite/obj-c++.dg/pr48187.mm trunk/gcc/testsuite/objc.dg/ivar-extra-semicolon.m trunk/gcc/testsuite/objc.dg/pr48187.m Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug objc++/49070] New: ObjC++ compiler fails to compile ObjC method invocations without keyword arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070
Summary: ObjC++ compiler fails to compile ObjC method
invocations without keyword arguments
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
The following testcase
/* Contributed by Nicola Pero nicola.p...@meta-innovation.com, May 2011. */
#include objc/objc.h
@interface A
- (id) method:(id)arg0 :(id)arg1;
@end
id function (A *x)
{
return [x method:x :x];
}
fails to compile as Objective-C++ with GCC 4.7.0:
[nicola@lampone ~]$ gcc test.mm -c
test.mm: In function ‘objc_object* function(A*)’:
test.mm:10:22: error: found ‘:’ in nested-name-specifier, expected ‘::’
test.mm:10:20: error: ‘x’ is not a class or namespace
test.mm:10:24: warning: ‘A’ may not respond to ‘-method:’ [enabled by default]
test.mm:10:24: warning: (Messages without a matching method signature [enabled
by default]
test.mm:10:24: warning: will be assumed to return ‘id’ and accept [enabled by
default]
test.mm:10:24: warning: ‘...’ as arguments.) [enabled by default]
[nicola@lampone ~]$
It compiles as Objective-C (ie, if you rename the file as test.m). It also
compiles with much older compilers, such as GCC 4.1.2.
This testcase was distilled from a bug reported by Banlu Kemiyatorn.
I'd consider this slightly higher priority than the usual Objective-C++
testcase because what is broken is actually part of the basic Objective-C
language syntax.
Thanks
[Bug objc++/49070] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.19 18:36:55 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-05-19 18:36:55 UTC --- Confirmed. The testcase fails to compile with gcc (GCC) 4.7.0 20110519 (experimental). Thanks
[Bug objc/48539] New: Missing warning when messaging a forward-declared class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48539
Summary: Missing warning when messaging a forward-declared
class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
The following testcase compiles with no warnings on GCC 4.7.0 20110326:
#include objc/objc.h
@class A;
@interface B
{
id isa;
}
+ (void) doSomething;
@end
void test (void)
{
[A doSomething];
}
While clang produces a hard error:
z.m:14:4: warning: receiver 'A' is a forward class and corresponding @interface
may not exist
[A doSomething];
^
z.m:9:1: note: method 'doSomething' is used for the forward class
+ (void) doSomething;
^
1 warning generated.
In this case, the behaviour of clang seems better. @class is really meant to
resolve recursive declarations; it should always be followed by the
corresponding @interface, particularly if you are going to message the class or
objects of the class.
I would say that GCC should produce at least a warning in this case!
There's also the issue of whether the following testcase should also produce
a warning:
#include objc/objc.h
@class A;
@interface B
{
id isa;
}
- (void) doSomething;
@end
void test (A *x)
{
[x doSomething];
}
This is slightly different in that it is an instance message, as opposed to
a class message. Neither GCC nor clang produce any warning or error here, but
it sounds like a warning similar to the one above would be very appropriate.
Thanks
[Bug objc/48539] Missing warning when messaging a forward-declared class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48539 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.10 11:11:54 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-04-10 11:11:54 UTC --- Yes, it's confirmed with both gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) and gcc (GCC) 4.7.0 20110326 (experimental) Thanks
[Bug objc/48527] New: Incorrect list of methods in @protocol used across compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48527
Summary: Incorrect list of methods in @protocol used across
compilation units
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
I'm using GCC 4.6.0.
The following example shows things working correctly when a protocol is used
in the same compilation unit:
[nicola@lampone ~]$ cat x1.m
#include objc/runtime.h
@protocol A
- (void) test;
@end
int main (void)
{
Protocol *p = @protocol (A);
struct objc_method_description method = protocol_getMethodDescription (p,
@selector (test),
YES,
YES);
printf (Protocol name is %s\n, protocol_getName (p));
printf (Method is %s, %s\n, sel_getName (method.name), method.types);
return 0;
}
[nicola@lampone ~]$ gcc x1.m -lobjc
x1.m: In function ‘main’:
x1.m:13:3: warning: incompatible implicit declaration of built-in function
‘printf’ [enabled by default]
[nicola@lampone ~]$ ./a.out
Protocol name is A
Method is test, v8@0:4
[nicola@lampone ~]$
This shows the protocol being recognized, and the full list of methods being
available when you introspect the protocol. :-)
But, if you move the @protocol to another compilation unit, things stop
working! :-(
[nicola@lampone ~]$ cat x2.m
#include objc/runtime.h
@protocol A;
int main (void)
{
Protocol *p = @protocol (A);
struct objc_method_description method = protocol_getMethodDescription (p,
@selector (test),
YES,
YES);
printf (Protocol name is %s\n, protocol_getName (p));
printf (Method is %s, %s\n, sel_getName (method.name), method.types);
return 0;
}
[nicola@lampone ~]$ gcc x2.m -c
x2.m: In function ‘main’:
x2.m:11:3: warning: incompatible implicit declaration of built-in function
‘printf’ [enabled by default]
[nicola@lampone ~]$ cat x3.m
#include objc/runtime.h
@protocol A
- (void) test;
@end
[nicola@lampone ~]$ gcc x3.m -c
[nicola@lampone ~]$ gcc x2.o x3.o -lobjc
[nicola@lampone ~]$ ./a.out
Protocol name is A
Method is null selector, (null)
[nicola@lampone ~]$
As you can see, in this case the protocol looks good if you check only the
name, but it isn't, since the method is not there in the list of protocol
methods!
Thanks
[Bug objc/48527] Incorrect list of methods in @protocol used across compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48527 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.09 10:47:15 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-04-09 10:47:15 UTC --- The testcases/examples confirm it. Thanks
[Bug objc/48376] gcc does not create an ivar for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48376 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.08 09:28:42 CC||nicola at gcc dot gnu.org Version|4.6.0 |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-04-08 09:28:42 UTC --- Thanks for reporting this. You are right that generating instance variables from properties is generally missing; it requires non-fragile instance variables, which we will only have (at least for the GNU runtime) in 4.7. By the way, I believe the instance variable should actually be generated by the @synthesize - so, the example you want is probably @interface Foo : Object @property (retain) id bar; @end @implementation Foo @synthesize bar; @end This also explains why non-fragile ivars are needed for this; the @interface will be in headers, and visible to subclasses, while the @synthesize (which actually adds the instance variable) will be in the implementation .m files and won't be visible to subclasses. So, subclasses will no longer see the full list of instance variables of the superclass; this only works if you have non-fragile instance variables, where the offset is calculated at runtime; if you access instance variables directly, by calculating the offset at compile time, you need the full list of instance variables to calculate the offset. So, before we can implement this, we have to implement non-fragile instance variables. ;-) Btw, the @property declaration itself wouldn't generate the instance variable, because you can still have a @property with no corresponding instance variable, for example if you declare your own setter/getter that may store the property value somewhere else (or maybe have a constant property ?). You wouldn't want an instance variable automatically generated in that case. Thanks
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.26 08:19:29 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-03-26 08:19:29 UTC --- Yes, this is unfortunately confirmed -- [nicola@lampone property]$ g++ cxx-property-1.mm -c cxx-property-1.mm:8:19: error: expected identifier before ‘namespace’ cxx-property-1.mm:8:19: error: expected ‘)’ before ‘namespace’ [nicola@lampone property]$ Thanks a lot for reporting it.
[Bug objc/31056] objc bogus warning when using const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31056 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.1 |4.7.0 --- Comment #6 from Nicola Pero nicola at gcc dot gnu.org 2011-03-25 21:02:18 UTC --- I don't expect this to be fixed in 4.6.x; I may work on it for 4.7.0, but I expect that the changes required won't be trivial. So I'm adjusting the target milestone. Of course, if someone else volunteers to fix it in the 4.6.x release line, please feel free to adjust the target. Thanks
[Bug bootstrap/48167] [4.7 Regression] Bootstrapping broken whenever obj-c++ is included in the list of languages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48167 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-03-21 10:25:40 UTC --- Author: nicola Date: Mon Mar 21 10:25:38 2011 New Revision: 171214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171214 Log: In gcc/: 2011-03-21 Nicola Pero nicola.p...@meta-innovation.com PR bootstrap/48167 * gengtype.c (files_rules): Added rule for cp/parser.h. In gcc/objcp/: 2011-03-21 Nicola Pero nicola.p...@meta-innovation.com PR bootstrap/48167 * Make-lang.in (START_HDRS): Added CXX_PARSER_H and CXX_PRETTY_PRINT_H. * config-lang.in (gtfiles): Added cp/parser.h and reorganized list so that it is more obvious that it is identical to the C++ one with the addition of some files at the end. Modified: trunk/gcc/ChangeLog trunk/gcc/gengtype.c trunk/gcc/objcp/ChangeLog trunk/gcc/objcp/Make-lang.in trunk/gcc/objcp/config-lang.in
[Bug bootstrap/48167] [4.7 Regression] Bootstrapping broken whenever obj-c++ is included in the list of languages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48167 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED AssignedTo|dnovillo at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-03-21 10:26:37 UTC --- This should now be fixed in trunk. Thanks
[Bug bootstrap/48167] [4.7 Regression] Bootstrapping broken whenever obj-c++ is included in the list of languages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48167 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org Summary|[4.7 Regression]|[4.7 Regression] |Bootstrapping revision |Bootstrapping broken |171075 fails on |whenever obj-c++ is |x86_64-apple-darwin10 |included in the list of ||languages --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-03-21 02:44:30 UTC --- It also happens on my GNU/Linux i386. If you include obj-c++ in the list of languages, then it won't bootstrap. It's been broken for 5 days now (I did produce a fix/patch, but it's never been approved so I couldn't apply it). As a sad consequence, we can expect all regression testers to simply remove Objective-C++ from the list of languages they test. Thanks
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-03-18 14:36:50 UTC --- Good point. Are you thinking of differences caused by protocol qualifiers, or by argframe layout information ? Thanks
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.18 15:22:25 Ever Confirmed|0 |1 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-03-18 15:22:25 UTC --- The problem showed up with argframe information in base ... which presumably means that something in base is getting that wrong :-( Ok - I see. So, something in base is trying to create a typed selector at runtime, and register it. The argframe information in the generated types doesn't match the existing one (probably because they are generated buggy, it's hard to generate them reliably), and the selector gets registered again. If we were using sel_types_match(), then gnustep-base wouldn't need to provide argframe information at all, assuming a selector with the same type already exists ? Or if it provides a buggy one, it would be discarded in favour of the existing one ? Assuming that most compiler-generated typed selectors (which include valid type information) are loaded in the runtime before any selector generated by gnustep-base (or anything else) on the fly at runtime (which may include buggy types), then this should generally work in making sure the correct types are used. :-) So, I guess we should do it as it should get things to work generally better. Is this a critical bug ? Ie, would it actually cause any visible trouble to users (as opposed to some inefficiency) ? If so, we need a testcase so we can backport it at some point to 4.6.x. I wonder, could we have a runtime function to take a type encoding without argframe info, and convert it to one with argframe info using the same algorithm the compiler uses? If we could do that, then we would not need the argframe info in the selectors at all. ;-) In fact, maybe we should get rid of it, or hide it more inside the runtime. It would be nice to audit exactly when and how it is used, and what the relationships are between the various parts. Ideally we'd get rid of the need for gnustep-base or even end-users to see or know about the argframe layout information. Let's have a chat about that offline. Thanks
[Bug objc/48187] infinite errors with misplaced [ in @interface definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48187 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.19 00:03:52 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-03-19 00:03:52 UTC --- Yes, confirmed. Well spotted! Thanks a lot
[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||nicola at gcc dot gnu.org --- Comment #10 from Nicola Pero nicola at gcc dot gnu.org 2011-03-19 00:22:52 UTC --- Mike, to clarify, the problem is that if you do not use -fno-strict-aliasing when compiling Objective-C, then compiling any largish Objective-C project (with perfectly correct Objective-C code) will generate many strict aliasing warnings. The rumours that GNUstep compiles everything with -fno-strict-aliasing are correct - that is the case. The reason is simply to avoid the warnings. But I guess that this means that all C code that is scattered inside Objective-C source files is generally not optimized as much as it could be. :-( So, it would be nice to clarify the problem once and for all, and make sure it is safe to use -fstrict-aliasing in Objective-C (and it doesn't generate warnings), then GNUstep could stop using -fno-strict-aliasing and people could get the full benefit of -O2. :-) The next step is producing a few testcases showing the actual warnings, so we have something to discuss about. :-) Thanks
[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753 --- Comment #11 from Nicola Pero nicola at gcc dot gnu.org 2011-03-19 01:24:47 UTC --- Having looked at some of the warnings generated in GNUstep if you compile with -fstrict-aliasing, they seem to be C warnings with little relevance to Objective-C (they mostly seem to be due to casting to (void **)). So on that side (the warnings) I guess I am inclined to join Mike and become skeptical of this issue. Unless the original report was that using -fstrict-aliasing would miscompile Objective-C code ? We need an example though. Thanks
[Bug libobjc/47922] New: [4.6 Regression] libobjc crashes with garbage collection in any real-life program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47922 Summary: [4.6 Regression] libobjc crashes with garbage collection in any real-life program Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: nic...@gcc.gnu.org From Richard Frith-Macdonald (r...@gnu.org) -- I enabled gc and built base using the new compiler runtime, but as soon as I start any program, it segfaults. It appears that a bug has crept in to the libobjc type encoding handling, so when you call class_ivar_set_gcinvisible() for any class, you get a crash. The crash is a divide by zero in objc_layout_structure_next_member() (at line 1278 desired_align is zero). I think the problem is that the exclamation mark denoting a weak variable is not being handled in the function. On line 1208 objc_skip_type_qualifiers() is not skipping past it, then on line 1211 objc_alignof_type() is returning zero. Looking at the ChangeLog, I think you broke this on 2010-09-26 changing _C_GCINVISIBLE from '!' to '|' when parts of the code use a literal exclamation mark rather than the symbolic constant. Is it too late to get this fixed? gc.c line 427 replace three lines with: new_type[len++] = _C_GCINVISIBLE; strcpy (new_type + len, type);
[Bug libobjc/47922] [4.6 Regression] libobjc crashes with garbage collection in any real-life program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47922 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-28 13:13:19 UTC --- Fixed in trunk (4.6.0). Thanks
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-02-22 18:31:43 UTC --- Resolved in trunk (4.6). Thanks
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:37:10
UTC ---
Hi Jakub,
@interface T
{
struct S *u;
};
@end
struct S * is a pointer, right ? So it's always the size of a pointer ?
In that case, I don't see any reason why it shouldn't be possible to use
it as an instance variable - it's a bug in the compiler if this is not
allowed. :-)
I think the new check in GCC 4.6 was supposed to catch the case
struct S
{
int s;
unsigned char *t[];
};
@interface T
{
struct S u;
};
@end
@implementation T
{
};
@end
this shouldn't be allowed. The reason is easy to understand:
* the list of instance variables in a class (inside @interface T { ... } @end)
is compiled into a struct in the end ;-)
* but, if the class is subclassed, the subclass instance variables are added
at the end of the superclass's struct
* so, if the list of instance variables ends with a flexible array member,
you get in trouble when you subclass the class, because the subclass
instance
variable struct will have a flexible array member *inside* (not at the end)
of the struct. ;-)
So, flexible array members should not be allowed as instance variables
anywhere.
This is what GCC 4.6 is trying to prevent.
But, in the testcase you show, the instance variable is not a flexible
array member; it's a pointer to a flexible array member. You can have
pointers to anything you want as instance variables. ;-)
I hope this helps with the Objective-C side.
Looking at the code, the check in encode_array() is not good enough. When the
instance variable type is encoded, the compiler will follow the pointer and
encode a description of the struct. The check in encode_array() will then
abort because the struct contains a flexible array member, without realizing
it is part of the struct pointed to.
I guess the fix should remove the check from encode_array() and move it higher
up when instance variables are added.
I can do the fix myself tonight (ie, in the next 12/24 hours) if you want.
Thanks
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.21 10:42:14 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 10:42:14 UTC --- Yes, confirmed. Good testcase. Thanks
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2011-02-21 14:33:14 UTC --- for ObjC I guess it depends if in @interface there are variables (then variables with flexible array members in theory could be treated there like ISO C99 treats variables), or they are treated as struct fields, in which cases fields with flex array members should be rejected I see your point. They are struct fields. Thanks
[Bug objc++/47711] [4.5/4.6 Regression] (even trivial) PCH fails for Objective-C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.20 14:53:13 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-20 14:53:13 UTC --- Confirmed. Patch to fix it submitted at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01318.html Thanks
[Bug objc/47813] Some ObjC tests failing on ia6-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-20 14:54:47 UTC --- This is fixed in trunk (but not really, the problem is just hidden). The following patch -- http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01297.html fixes it for real though. Thanks
[Bug objc++/47711] [4.5/4.6 Regression] (even trivial) PCH fails for Objective-C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.6.0 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-02-20 17:27:57 UTC --- Fixed in trunk. Thanks
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|4.6.0 | --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-02-20 17:42:17 UTC --- Fixed in trunk. Thanks
[Bug objc/47813] Some ObjC tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-02-20 17:53:54 UTC --- This is fixed in trunk, and the patch was applied. An explicit testcase that -Wpadded generates no warnings even when ObjC metadata is generated was added. Thanks
[Bug objc/47813] Some ObjC tests failing on ia6-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.19 14:33:59 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-19 14:33:59 UTC --- I got access to a ia64 linux gnu machine. The regression is present in revision 170260. Here is the detail log Executing on host: /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc -B/home/nicola/GCC/build-trunk-full-serial/gcc/ /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m -fgnu-runtime -Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc -B/home/nicola/GCC/build-trunk-full-serial/ia64-unkn own-linux-gnu/./libobjc/.libs -L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./bitfield-3.exe(timeout = 300) spawn /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc -B/home/nicola/GCC/build-trunk-full-serial/gcc/ /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m -fgnu-runtime -Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc -B/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/. /libobjc/.libs -L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./bitfield-3.exe /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:20:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:27:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:32:16: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:33:16: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning: padding struct to align 'defs' [-Wpadded] output is: /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:20:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:27:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:32:16: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:33:16: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning: padding struct to align 'defs' [-Wpadded] PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 20) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 27) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 32) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 33) FAIL: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors) Excess errors: /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-3.m:49:1: warning: padding struct to align 'defs' [-Wpadded] --- Executing on host: /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc -B/home/nicola/GCC/build-trunk-full-serial/gcc/ /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m -fgnu-runtime -Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc -B/home/nicola/GCC/build-trunk-full-serial/ia64-unkn own-linux-gnu/./libobjc/.libs -L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./bitfield-5.exe(timeout = 300) spawn /home/nicola/GCC/build-trunk-full-serial/gcc/xgcc -B/home/nicola/GCC/build-trunk-full-serial/gcc/ /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m -fgnu-runtime -Wpadded -I/home/nicola/GCC/trunk/gcc/testsuite/../../libobjc -B/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/. /libobjc/.libs -L/home/nicola/GCC/build-trunk-full-serial/ia64-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./bitfield-5.exe /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:24:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:33:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:40:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:52:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:57:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:70:1: warning: padding struct size to alignment boundary [-Wpadded] /home/nicola/GCC/trunk/gcc/testsuite/objc.dg/bitfield-5.m:74:16: warning
[Bug objc/47813] New: Some ObjC tests failing on ia6-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813 Summary: Some ObjC tests failing on ia6-suse-linux-gnu Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: nic...@gcc.gnu.org In revision 170242 on ia64-suse-linux-gnu, we had === objc Summary === # of expected passes2897 # of expected failures10 # of unsupported tests75 /usr/local/gcc/gcc-20110217/Build/gcc/xgcc version 4.6.0 20110217 (experimental) [trunk revision 170242] (GCC) (as reported in http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg01899.html) while in revision 170268, on the same machine/tester, we had === objc tests === Running target unix FAIL: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors) FAIL: objc.dg/bitfield-5.m -fgnu-runtime (test for excess errors) FAIL: objc.dg/layout-1.m -fgnu-runtime (test for excess errors) === objc Summary === # of expected passes2894 # of unexpected failures3 # of expected failures10 # of unsupported tests75 /usr/local/gcc/gcc-20110218/Build/gcc/xgcc version 4.6.0 20110218 (experimental) [trunk revision 170268] (GCC) (as reported in http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02026.html) As the big Apple 64-bit runtime patch was committed at revision 170260, this suggests it broke Objective-C on ia64-suse-linux-gnu. Thanks
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-19 05:09:33 UTC --- Submitted a patch that fixes it. http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01282.html Thanks
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.18 03:03:14 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-02-18 03:03:14 UTC --- Yes, confirmed. Thanks
[Bug objc/47682] unused-but-set-variabled warning when using fast enumeration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47682 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.10 19:24:33 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-02-10 19:24:33 UTC --- Yes, this is supposed to have been fixed, even if not by me ;-) It was Iain who fixed it -- http://gcc.gnu.org/ml/gcc-cvs/2011-01/msg00219.html I see that Jos is using gcc version 4.6.0 20101219 (experimental) (GCC), which I'd expect wouldn't include the fix. I asked him (offline) if he could try again with a newer compiler. It works for me with GNUstep and GCC 4.6 trunk. Thanks
[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-02-09 19:37:19 UTC --- This failure is no longer reported in any of the automated testsuite checkers. I have to assume it was fixed on 10 January. Thanks
[Bug c/43082] [4.3/4.4/4.5/4.6 Regression] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|4.6.0 | --- Comment #10 from Nicola Pero nicola at gcc dot gnu.org 2011-01-28 00:08:01 UTC --- Fixed in GCC trunk/4.6.0. Thanks
[Bug c/43082] [4.3/4.4/4.5/4.6 Regression] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082 --- Comment #9 from Nicola Pero nicola at gcc dot gnu.org 2011-01-27 02:09:19 UTC --- Author: nicola Date: Thu Jan 27 02:09:13 2011 New Revision: 169319 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169319 Log: In gcc/: 2011-01-26 Nicola Pero nicola.p...@meta-innovation.com PR c/43082 * c-typeck.c (c_objc_common_truthvalue_conversion): If we are passed a VOID_TYPE expression, immediately emit an error and return error_mark_node. In gcc/testsuite/: 2011-01-26 Nicola Pero nicola.p...@meta-innovation.com Andrew Pinski pins...@gmail.com PR c/43082 * gcc.dg/pr43082.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr43082.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/22297] [4.3/4.4/4.5/4.6 Regression] missing uninitialized warning (builtin functions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||nicola at gcc dot gnu.org
Known to work||4.6.0
Resolution||FIXED
Target Milestone|4.3.6 |4.6.0
--- Comment #11 from Nicola Pero nicola at gcc dot gnu.org 2011-01-19
21:40:14 UTC ---
This works for me with GCC 4.6.0 --
[nicola@lampone ~]$ cat x.c
#include string.h
int g(char *);
int f(void)
{
char *s;
strcpy(s,s);
return g(s);
}
[nicola@lampone ~]$ gcc x.c -Wall -c -O2
x.c: In function ‘f’:
x.c:8:3: warning: ‘s’ is used uninitialized in this function [-Wuninitialized]
[nicola@lampone ~]$
The same doesn't work with GCC 4.1.2, where the same gcc command generates
no warnings at all.
So it looks like the problem has been fixed :-)
Thanks
[Bug c/43082] [4.3/4.4/4.5/4.6 Regression] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org Known to work||4.1.2 Summary|ICE in tree check: expected |[4.3/4.4/4.5/4.6 |class 'type', have |Regression] ICE in tree |'exceptional' (error_mark) |check: expected class |in |'type', have 'exceptional' |useless_type_conversion_p |(error_mark) in ||useless_type_conversion_p Known to fail|| --- Comment #8 from Nicola Pero nicola at gcc dot gnu.org 2011-01-19 00:55:38 UTC --- This is a regression since my stock RedHat gcc 4.1.2 compiler doesn't ICE. I have a patch that should address Joseph's comments to Andrew's original patch. I'll submit it once it's finished testing. Thanks
[Bug objc/47314] Incorrect multiple selectors warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-01-19 02:54:56 UTC --- Fixed in trunk (4.6.0). Thanks
[Bug objc/47314] Incorrect multiple selectors warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-01-17 22:17:50 UTC --- Author: nicola Date: Mon Jan 17 22:17:47 2011 New Revision: 168934 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168934 Log: In gcc/objc/: 2011-01-17 Nicola Pero nicola.p...@meta-innovation.com PR objc/47314 * objc-act.c (finish_objc): When calling check_duplicates to check duplicated instance methods, set 'is_class' to 0, not 1. In gcc/testsuite/: 2011-01-17 Nicola Pero nicola.p...@meta-innovation.com PR objc/47314 * objc.dg/selector-warn-1.m: New. * obj-c++.dg/selector-warn-1.mm: New. Added: trunk/gcc/testsuite/obj-c++.dg/selector-warn-1.mm trunk/gcc/testsuite/objc.dg/selector-warn-1.m Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog
[Bug c/46822] printf( %f ) segv when called from pthread_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46822 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.17 22:49:07 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-01-17 22:49:07 UTC --- Isdmter thanks for your report and the testcase. The attached testcase works for me using GCC 4.6.0 (pre-release) -- gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc/trunk7/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../trunk7/configure --prefix=/opt/gcc/trunk7 --enable-languages=c,objc,c++,obj-c++ --enable-objc-gc --with-gmp=/opt/gcc/auxiliary/ --with-mpfr=/opt/gcc/auxiliary/ --with-mpc=/opt/gcc/auxiliary/ --enable-checking=release : (reconfigured) ../trunk7/configure --prefix=/opt/gcc/trunk7 --enable-objc-gc --with-gmp=/opt/gcc/auxiliary/ --with-mpfr=/opt/gcc/auxiliary/ --with-mpc=/opt/gcc/auxiliary/ --enable-checking=release --enable-languages=c,c++,lto,objc,obj-c++ --no-create --no-recursion Thread model: posix gcc version 4.6.0 20110116 (experimental) (GCC) [nicola@lampone ~]$ gcc -Wall -save-temps -o main -pthread -lpthread main.c [nicola@lampone ~]$ ./main 0 0.00 0 0.00 [nicola@lampone ~]$ I also tried on a x86_64-unknown-linux-gnu AMD machine, similar to yours, and it works fine there too. Maybe you could manage to try with GCC 4.6.0 (prerelease) and confirm that you're still seeing the bug there ? Thanks
[Bug c/44515] improve message for missing ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-01-17 23:34:31 UTC --- I like Joseph's suggestion - I had been thinking for a while about the C/ObjC FE error messages and came to the same conclusion: ideally it should prominently mention the last valid token (that's how you think about the error, the code is valid until bar(), then there is an error), but also mentioning the next, unexpected token helps you find the error location when you're looking at the code. So, shall we go for error: missing ‘;’ after expression and before ‘}’ then ? I guess we'd need to change all the errors in sync. Thanks
[Bug c/44513] improve column number and text of format warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513
Nicola Pero nicola at gcc dot gnu.org changed:
What|Removed |Added
CC||nicola at gcc dot gnu.org
--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-01-17 23:48:16
UTC ---
I tested GCC 4.6.0, and it seems to have been modified to match what you
want:
cat -n test.c
1 #include stdio.h
2
3 void
4 foo (int i)
5 {
6printf (%d%d, i);
7 }
gcc test.c -c -Wall
test.c: In function ‘foo’:
test.c:6:3: warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat]
I personally preferred GCC's original error message; when you have lots of
arguments, the new system will generate lots of error messages, all of them
technically correct, but providing a confusing picture. Eg,
void foo (int i, float f, int j, float c)
{
printf (%d%f%d%f, f, j, c);
}
(where the missing argument is the first one) will generate 4 error messages
now:
test.c: In function ‘foo’:
test.c:5:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2
has type ‘double’ [-Wformat]
test.c:5:3: warning: format ‘%f’ expects argument of type ‘double’, but
argument 3 has type ‘int’ [-Wformat]
test.c:5:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 4
has type ‘double’ [-Wformat]
test.c:5:3: warning: format ‘%f’ expects a matching ‘double’ argument
[-Wformat]
In this context, I would prefer the traditional GCC error message (too few
arguments), which is a simple, clear summary of the problem.
Thanks
[Bug c/44513] improve column number and text of format warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-01-17 23:51:49 UTC --- In this context, I would prefer the traditional GCC error message (too few arguments), which is a simple, clear summary of the problem. Except that older GCCs still generated 4 errors here, so I'm whining about nothing. ;-) test4.c: In function ‘foo’: test4.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘double’ test4.c:5: warning: format ‘%f’ expects type ‘double’, but argument 3 has type ‘int’ test4.c:5: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘double’ test4.c:5: warning: too few arguments for format Anyway, I'll resolve it as it's been implemented in 4.6. Thanks
[Bug c/44513] improve column number and text of format warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Target Milestone|--- |4.6.0
[Bug objc/47314] New: Incorrect multiple selectors warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314
Summary: Incorrect multiple selectors warning
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
A trivial typo in objc-act.c means that the following testcase emits the wrong
warning when compiled with -Wselector:
/* Contributed by Nicola Pero nicola.p...@meta-innovation.com, January 2011.
*/
/* { dg-options -Wselector } */
/* { dg-do compile } */
#include objc/objc.h
@interface MyObject
- (void) method;
@end
@interface MyObject2;
- (int) method;
@end
GCC 4.6.0 produces the warning
selector-warn-1.m:13:1: warning: multiple selectors named ‘+method’ found
[enabled by default]
selector-warn-1.m:8:1: note: found ‘-(void)method’
selector-warn-1.m:12:1: note: also found ‘-(int)method’
Note that the selector is wrongly referred to as '+method' instead of
'-method'.
Thanks
