[Bug testsuite/46998] [4.6 Regression] FAIL: objc.dg/exceptions-4.m

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46998

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nicola at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Nicola Pero  2010-12-18 00:23:04 
UTC ---
I fixed it in trunk.

Thanks

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 18:31:43
 CC||nicola at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-19 18:31:43 
UTC ---
Hi Jonathan

nice to hear from you again (we met at Fosdem a few years ago, not sure you
remember me; I do remember you). ;-)

You are right that the GNU runtime does [[x retain] autorelease] before 
returning the value for an object, nonatomic synthesized property .  The reason 
everyone but Apple does it, I suppose, it is because everyone felt it is a bug 
in the Apple implementation. ;-)

The additional retain/autorelease should make it safer (but slower) than the
Apple implementation; I don't think it should cause it to behave differently
(other than prevent the object from being released until the next autorelease
pool is emptied).  Do you have a testcase where an actual difference in 
behaviour (other than the object being safe to use for longer, and the 
implementation with autorelease/retain being obviously slower) can be seen ?

I guess you're concerned about performance ?

Do you have any evidence that Apple did that on purpose and it's not a bug ?  
If you have any such evidence [ie, they won't "fix" it at the next release and 
we'll suddenly be the "broken" ones ;-)], we should certainly change it to 
behave in the same way.

Maybe we should change it to behave in the same way anyway ;-)

Thanks

PS: Your contribution to GCC's libobjc would be much appreciated.  The existing 
implementation of properties accessors is fairly finished though --

http://gcc.gnu.org/viewcvs/trunk/libobjc/accessors.m?revision=165903&view=markup

It would be a one-liner to make the change if we want to.

[Bug libobjc/45953] Registering untyped selector mutates existing selector

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 18:35:08
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-19 18:35:08 
UTC ---
Yes, it's confirmed.

Thanks

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #3 from Nicola Pero  2010-12-19 19:10:29 
UTC ---
Author: nicola
Date: Sun Dec 19 19:10:26 2010
New Revision: 168070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168070
Log:
In libobjc/:
2010-12-19  Nicola Pero  

PR libobjc/47012
* accessors.m (objc_getProperty): If not atomic, do not
retain/autorelease the returned value. (Problem reported by

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/accessors.m

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #4 from Nicola Pero  2010-12-19 19:12:33 
UTC ---
Yes, I was actually thinking about this, and you're right - it makes sense not
to use retain/autorelease! ;-)

'nonatomic' means that other threads are not involved.  Which also means that
the programmer calling the accessor has full control of what happens (there
aren't alternative flows of execution that may jump in); he should do the
retain/autorelease himself if there is a risk that something he does while
using the object returned may call the accessor setter and trigger a release of
the object; else, he can get away without a retain/autorelease and get a good
speedup.

And doing the same that Apple does is obviously helpful for portability.

So I made the change in subversion.

Thanks

PS: GCC is currently in bug-fixing mode only for 4.6 so we can't accept
non-bug-fix changes, but as soon as it reopens, you're very welcome to
contribute.  Faster method lookup sounds very exciting (and non-trivial).

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Nicola Pero  2010-12-19 19:14:49 
UTC ---
Fixed in trunk (will be GCC 4.6).

Thanks

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #7 from Nicola Pero  2010-12-21 10:56:33 
UTC ---
Yes, I'll visit Fosdem - let's meet up there.

> In the code you linked, is that objc_mutex_t a spinlock? If not,
> this might be performance problem.

You are right, it's a normal lock.  Currently, libobjc just uses plain mutex
locks everywhere.  We should improve on that in GCC 4.7 - there's lot that
can be done.

Thanks

[Bug libobjc/47012] nonatomic Properties behave wrong

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #9 from Nicola Pero  2010-12-21 11:38:56 
UTC ---
Sure, go ahead and create a bug for it.  We can make the change for 4.6 if we
make it safe.  By the way, changing configure.ac is not a problem, we can do
that, particularly if it makes the change safer. ;-)

It could make the change safer - we could check that spinlocks are available,
and use them if so; if not, we just fall back to using a standard mutex, which
is slower but works on all platforms.

Thanks

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.21 11:47:22
 CC||nicola at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-21 11:47:22 
UTC ---
Yes, and it would be good to fix it for 4.6.

Patches are welcome. ;-)

Thanks

[Bug libobjc/45953] Registering untyped selector mutates existing selector

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953

--- Comment #2 from Nicola Pero  2010-12-21 13:44:09 
UTC ---
Author: nicola
Date: Tue Dec 21 13:44:04 2010
New Revision: 168115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168115
Log:
In libobjc/:
2010-12-21  Nicola Pero  

PR libobjc/45953
* selector.c (__sel_register_typed_name): When registering a new
selector with the same name as an existing one, reuse the existing
name string.  Also updated types, casts and comments in the whole
function.

In gcc/testsuite/:
2010-12-21  Nicola Pero  

PR libobjc/45953
* objc.dg/libobjc-selector-1.m: New test.


Added:
trunk/gcc/testsuite/objc.dg/libobjc-selector-1.m
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libobjc/ChangeLog
trunk/libobjc/selector.c

[Bug libobjc/45953] Registering untyped selector mutates existing selector

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953

Nicola Pero  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  2010-12-21 13:47:23 
UTC ---
Fixed in trunk, with testcase.

Thanks

[Bug libobjc/16110] +load is not called on all the categories.

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16110

--- Comment #6 from Nicola Pero  2010-12-21 15:34:22 
UTC ---
Author: nicola
Date: Tue Dec 21 15:34:19 2010
New Revision: 168122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168122
Log:
In libobjc/:
2010-12-21  Nicola Pero  

PR libobjc/16110
* init.c (__objc_send_message_in_list): Renamed to
__objc_send_load_using_method_list.  Do not take an 'op' argument.
Register the 'load' selector if needed.
(__objc_send_load): Do not register the 'load' selector.  Updated
call to __objc_send_message_in_list.
(__objc_create_classes_tree): Add the class of any claimed
category that was loaded in the module to the list of classes for
which we try to execute +load.

In gcc/testsuite/:
2010-12-21  Nicola Pero  

PR libobjc/16110
* objc.dg/special/special.exp: Added new test.
* objc.dg/special/load-category-1.m: New.
* objc.dg/special/load-category-1a.m: New.
* objc.dg/special/load-category-1.h: New.


Added:
trunk/gcc/testsuite/objc.dg/special/load-category-1.h
trunk/gcc/testsuite/objc.dg/special/load-category-1.m
trunk/gcc/testsuite/objc.dg/special/load-category-1a.m
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/objc.dg/special/special.exp
trunk/libobjc/ChangeLog
trunk/libobjc/init.c

[Bug libobjc/16110] +load is not called on all the categories.

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16110

Nicola Pero  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.6.0

--- Comment #7 from Nicola Pero  2010-12-21 15:36:08 
UTC ---
I fixed this in trunk.

Thanks

[Bug libobjc/18575] objc_class subclass_list and sibling_class not filled out after dlopen

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18575

Nicola Pero  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.6.0

--- Comment #3 from Nicola Pero  2010-12-21 21:56:28 
UTC ---
This is fixed in trunk; I added a call to __objc_resolve_class_links()
at the end of __objc_exec_class().

Thanks

[Bug libobjc/18764] segfault in libobjc when sending a message to a conflicting class

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764

--- Comment #8 from Nicola Pero  2010-12-21 22:49:44 
UTC ---
Author: nicola
Date: Tue Dec 21 22:49:37 2010
New Revision: 168139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168139
Log:
In libobjc/:
2010-12-21  Nicola Pero  

PR libobjc/18764
* class.c (__objc_add_class_to_hash): Return YES if the class was
added, and NO if it already existed.
* init.c (__objc_init_class): If __objc_add_class_to_hash returns
NO, then abort the program with an error message.
* objc-private/runtime.h (__objc_add_class_to_hash): Updated
declaration.

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/class.c
trunk/libobjc/init.c
trunk/libobjc/objc-private/runtime.h

[Bug libobjc/18764] segfault in libobjc when sending a message to a conflicting class

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764

Nicola Pero  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.6.0

--- Comment #9 from Nicola Pero  2010-12-21 22:51:33 
UTC ---
I fixed this in trunk to check and abort with an ordinate error message when a
class with the same name of an existing one is loaded.

Thanks

[Bug objc/47070] New: Error message mentioning _OBJC_INSTANCE_0

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47070

   Summary: Error message mentioning _OBJC_INSTANCE_0
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


The following testcase --

#include 

int main (void)
{
  if (@"Test")
return 0;

  return 1;
}

when compiled with the GNU runtime,

gcc test.m -lobjc -fgnu-runtime -Wall

produces an error message which is correct, but confusing for users --

test.m: In function ‘main’:
test.m:5:7: warning: the address of ‘_OBJC_INSTANCE_0’ will always evaluate as
‘true’ [-Waddress]

The error message is confusing because _OBJC_INSTANCE_0 is the internal name
used for @"Test".

Thanks

[Bug objc/47070] Error message mentioning _OBJC_INSTANCE_0

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47070

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.27 17:34:22
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-27 17:34:22 
UTC ---
Confirmed - I get this error message both on GNU/Linux 32bit and Apple 32bit.

Thanks

[Bug objc/47073] New: ICE when producing error for method argument which "does not have know size"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47073

   Summary: ICE when producing error for method argument which
"does not have know size"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


The following testcase crashes the compiler.  It is a regression; it works with
my stock "gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)" compiler --

[nic...@nicola objc.dg]$ gcc incomplete-type-1.m -c
cc1obj: error: type ‘({anonymous})’ does not have a known size
cc1obj: error: type ‘({anonymous})’ does not have a known size

(the error message is not great though)

Instead, with GCC 4.6 I get --

[nic...@nicola objc.dg]$ gcc incomplete-type-1.m -c -Wall
‘
tree check: expected tree that contains ‘decl minimal’ structure, have
‘enumeral_type’ in c_tree_printer, at c-objc-common.c:110
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Thanks

/* Contributed by Nicola Pero , December 2010.
 */
/* { dg-do compile } */

#include 

enum type1;
struct type2;

@interface MyObject
- (void) method1: (enum type1)argument;
- (void) method2: (struct type2)argument;
@end

@implementation MyObject
- (void) method1: (enum type1)argument /* { dg-error "does not have a known
size" } */
{
  return;
}
- (void) method2: (struct type2)argument /* { dg-error "does not have a known
size" } */
{
  return;
}
@end

[Bug objc/47073] ICE when producing error for method argument which "does not have know size"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47073

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.27 23:16:28
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-27 23:16:28 
UTC ---
Confirmed for GCC 4.6 as of 28 December 2010.

Thanks

[Bug objc/47073] ICE when producing error for method argument which "does not have know size"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47073

--- Comment #2 from Nicola Pero  2010-12-28 00:29:44 
UTC ---
Submitted a patch to gcc-patches.

Thanks

[Bug objc/47073] ICE when producing error for method argument which "does not have know size"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47073

--- Comment #3 from Nicola Pero  2010-12-28 03:41:02 
UTC ---
Author: nicola
Date: Tue Dec 28 03:40:58 2010
New Revision: 168285

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168285
Log:
In gcc/testsuite/:
2010-12-28  Nicola Pero  

PR objc/47073
* objc.dg/incomplete-type-1.m: New test.

In gcc/objc/:
2010-12-28  Nicola Pero  

PR objc/47073
* objc-act.c (encode_method_prototype): Fixed both location and
format string of error "type %qT does not have a known size".

Added:
trunk/gcc/testsuite/objc.dg/incomplete-type-1.m
Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/47073] ICE when producing error for method argument which "does not have know size"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47073

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #4 from Nicola Pero  2010-12-28 04:36:08 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/47075] New: Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075

   Summary: Missed deprecation warnings for @property when using
getter/setter directly
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


When you deprecate a @property, and then use the getter/setter directly, no
deprecation warning is currently produced.  That is, the following fails --

/* Contributed by Nicola Pero , October 2010. 
*/
/* { dg-do compile } */

/* Test that deprecation warnings are produced when a setter/getter of
   a @property is used directly.  */

#include 

@interface MyClass
{
  Class isa;
  int variable;
} 
@property (assign, nonatomic) int property __attribute__ ((deprecated));
@end

void foo (void)
{
  MyClass *object = nil;

  if ([object property] > 0)  /* { dg-warning "is deprecated" } */
{
  [object setProperty: 43]; /* { dg-warning "is deprecated" } */ 
}
}

Thanks

[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.28 15:40:37
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-28 15:40:37 
UTC ---
Confirmed.

Thanks

[Bug objc/47076] New: Protocol referenced in @interface declarations should be defined

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076

   Summary: Protocol referenced in @interface declarations should
be defined
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


All the protocols in the list of protocols in an @interface declaration should
have been defined; forward-references are not enough.  Here is a testcase --

/* Contributed by Nicola Pero , December 2010.
 */
/* { dg-do compile } */

/* Test that all protocols appearing in @interface declarations are 
   real (ie, we saw a full @protocol definition with list of methods),  
   and not just forward-references (ie, "@protocol NSObject;").  */

#include 

@protocol MyProtocol;

@protocol MyProtocol2
- (int)method2;
@end

@interface MyClass  /* { dg-warning "definition of protocol
.MyProtocol. not found" } */
@end

@interface MyClass2  /* Ok */
@end

@interface MyClass2 (Category)   /* { dg-warning "definition of
protocol .MyProtocol. not found" } */
@end

Thanks

[Bug objc/47076] Protocol referenced in @interface declarations should be defined

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.28 16:30:49
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-28 16:30:49 
UTC ---
Confirmed

Thanks

[Bug objc/47077] New: ICE on invalid code (method implementation outside of implementation context)

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47077

   Summary: ICE on invalid code (method implementation outside of
implementation context)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


Here is a minimal testcase --

- (int) method: (int)argument
{
  return argument;
}

The crash is due to the fact that, when we find a method outside an
implementation context, we don't even create a function context.  So, all the
code in the method will be parsed in a void and crash the compiler at the first
reference to the local bind or such like.

We most likely ought to review the code start/closing the method, and if the
method is outside of an implementation context, start/close it normally but
without associating it with a class.  I suppose 'self' could be set to be of
type 'id'.

Thanks

[Bug objc/47078] New: ICE on invalid type

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078

   Summary: ICE on invalid type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


The following minimal testcase seems to crash the compiler --

@implementation MyClass
- (x) method
{
  return 0;
}
@end

Thanks

[Bug objc/47076] Protocol referenced in @interface declarations should be defined

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076

--- Comment #2 from Nicola Pero  2010-12-29 01:16:59 
UTC ---
Author: nicola
Date: Wed Dec 29 01:16:55 2010
New Revision: 168307

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168307
Log:
In gcc/objc/:
2010-12-28  Nicola Pero  

PR objc/47076
* objc-act.c (lookup_protocol): Added 'definition_required'
argument.  If 'definition_required', and the protocol is not
defined, emit a warning.
(objc_declare_protocols): Updated call to lookup_protocol.
(start_protocol): Same change.
(check_protocol_recursively): Same change.
(objc_build_protocol_expr): Same change.
(lookup_and_install_protocols): Added definition_required argument.
Pass it to lookup_protocol.
(objc_get_protocol_qualified_type): Updated call to
lookup_and_install_protocols.
(start_class): Updated calls to lookup_and_install_protocols; pass
true to 'definition_required' to get the warnings.
(start_protocol): Updated calls to lookup_and_install_protocols.

In gcc/testsuite/:
2010-12-28  Nicola Pero  

PR objc/47076
* objc.dg/protocol-forward-1.m: New.
* obj-c++.dg/protocol-forward-1.mm: New.
* objc.dg/attributes/proto-attribute-2.m: Updated.
* objc.dg/class-protocol-1.m: Updated.
* obj-c++.dg/attributes/proto-attribute-2.mm: Updated.
* obj-c++.dg/class-protocol-1.mm: Updated.

Added:
trunk/gcc/testsuite/obj-c++.dg/protocol-forward-1.mm
trunk/gcc/testsuite/objc.dg/protocol-forward-1.m
Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/attributes/proto-attribute-2.mm
trunk/gcc/testsuite/obj-c++.dg/class-protocol-1.mm
trunk/gcc/testsuite/objc.dg/attributes/proto-attribute-2.m
trunk/gcc/testsuite/objc.dg/class-protocol-1.m

[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075

--- Comment #2 from Nicola Pero  2010-12-29 12:22:13 
UTC ---
Author: nicola
Date: Wed Dec 29 12:22:09 2010
New Revision: 168315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168315
Log:
In gcc/c-family/:
2010-12-29  Nicola Pero  

PR objc/47075
* c-objc.h (objc_finish_message_expr): Added argument to
prototype.

In gcc/objc/:
2010-12-29  Nicola Pero  

PR objc/47075
* objc-act.h (PROPERTY_REF_DEPRECATED_GETTER): New.
* objc-tree.def (PROPERTY_REF): Increased the number of operands
from 3 to 4.
* objc-act.c (objc_finish_message_expr): Added optional argument
allowing to return the deprecated method prototype for deprecated
methods, instead of immediately emitting the deprecation warning.
(objc_maybe_build_component_ref): Do not warn for a deprecated
property.  When building the getter call, get the deprecated
method prototype from objc_finish_message_expr() and put it into
the PROPERTY_REF.
(objc_build_class_component_ref): Same change.
(finish_class): Mark the getter and setter as deprecated if they
are generated from a deprecated property.
(objc_gimplify_property_ref): If the getter is deprecated, emit a
deprecation warning.
(objc_build_setter_call, objc_build_message_expr,
objc_finish_foreach_loop): Updated call to
objc_finish_message_expr.

In gcc/objcp/:
2010-12-29  Nicola Pero  

* objcp-lang.c (objcp_tsubst_copy_and_build): Update call to
objc_finish_message_expr.

In gcc/testsuite/:
2010-12-29  Nicola Pero  

PR objc/47075
* objc.dg/property/at-property-deprecated-1.m: Updated.
* objc.dg/property/at-property-deprecated-2.m: New.
* objc.dg/property/dotsyntax-deprecated-1.m: New.
* obj-c++.dg/property/at-property-deprecated-1.mm: Updated.
* obj-c++.dg/property/at-property-deprecated-2.mm: New.
* obj-c++.dg/property/dotsyntax-deprecated-1.mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/property/at-property-deprecated-2.mm
trunk/gcc/testsuite/obj-c++.dg/property/dotsyntax-deprecated-1.mm
trunk/gcc/testsuite/objc.dg/property/at-property-deprecated-2.m
trunk/gcc/testsuite/objc.dg/property/dotsyntax-deprecated-1.m
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-objc.h
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/objc/objc-act.h
trunk/gcc/objc/objc-tree.def
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/objcp-lang.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/property/at-property-deprecated-1.mm
trunk/gcc/testsuite/objc.dg/property/at-property-deprecated-1.m

[Bug objc/47118] New: ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47118

   Summary: ICE on incorrect parameter to @synchronized()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


Here is a testcase that crashes GCC 4.6 --

typedef struct { float x; float y; } point;

int test (id object)
{
  point x;
  @synchronized (x)
{
  return 1;
}
}

The compiler is not checking the type of the argument of @synchronized() and is
not dealing with unexpected types correctly.

Thanks

[Bug objc/47118] ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47118

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.29 15:21:12
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2010-12-29 15:21:12 
UTC ---
Confirmed on trunk, 29 December 2010.

Thanks

[Bug objc/47076] Protocol referenced in @interface declarations should be defined

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47076

Nicola Pero  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  2010-12-29 15:32:10 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/47075] Missed deprecation warnings for @property when using getter/setter directly

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47075

Nicola Pero  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  2010-12-29 15:32:59 
UTC ---
Fixed in trunk.

Thanks

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

--- Comment #2 from Nicola Pero  2010-12-29 16:10:51 
UTC ---
I'm actually not very convinced by this any more; we probably need some
benchmarks. ;-)

The problem is that property accessors are basically general purpose routines
that may be used in the most varied situations.

So, we have very little control or knowledge over when and how they are used --

 * we don't know how many CPUs or cores the user has

 * we don't know how many threads the user is starting

 * we don't know how many threads are sharing a CPU or core

 * we don't know how intensively the user is using the property accessors

Spinlocks are appropriate when certain conditions are met; but in this case,
it seems impossible to be confident that these are met.  A user may write a
program with 3 or 4 threads running on his 1 CPU/core machine, which constantly
read/write an atomic synthesized property to synchronize between themselves. 
Why not; but then, spinlocks would actually degrade performance instead of
improving it.

Traditional locks may be slower if you a low contention case, but work
consistently OK in all conditions.

For me, the key problem is that:

 * spinlocks are better/faster if there is low contention and very little
chance that two threads enter the critical region (inside the accessors) at the
same time.

 * the difference in performance between mutexes and spinlocks only matters in
the program performance if the accessors are called very often.

But these two things conflict with each other ;-)

For example, if a spinlock makes the accessor 2x as fast as with a mutex, but
the program only spends 0.1% of its time calling the accessors, then the
difference in performance on the whole program would be of the order of 0.05%;
then, we prefer a mutex since the performance is more consistent and it has no
"worst-case" scenarios.

If the program spends more (say, 10%) of its time calling the accessors, then
the difference in performance would matter (it would be something like 5%), but
because the program is spending so much time in accessors, if the program is
multi-threaded there is high contention, and spinlocks don't perform well any
more - in fact, the worst-case scenarios (where lots of CPU is wasted spinning
and making no progress) may appear. (keep in mind that as we're sharing locks
across different objects/properties, even if the different threads are calling
accessors of different objects/properties, the locks would still be contended).

The only case where spinlocks really help is if the program spends lots of time
calling accessors, and is not multi-threaded.  In which case, the programmer
could get a huge speed-up by simply declaring the properties non-atomic.

So, I'm not sure there is a good case for spinlocks.

It may be good to try some benchmarks to get a feeling for the difference in
performance between mutexes and spinlocks.  Would using spinlocks make
accessors 2x faster ? 10x faster ? 10% faster ?

Thanks

[Bug objc/47118] ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47118

--- Comment #2 from Nicola Pero  2010-12-29 21:52:03 
UTC ---
Author: nicola
Date: Wed Dec 29 21:52:00 2010
New Revision: 168326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168326
Log:
In gcc/objc/:
2010-12-29  Nicola Pero  

PR objc/47118
* objc-act.c (objc_build_synchronized): Check the argument of
@synchronized and emit an appropriate error if it is not a valid
Objective-C object.  Deal gracefully with that case.  Updated
comments and variable names.

In gcc/testsuite/:
2010-12-29  Nicola Pero  

PR objc/47118
* objc.dg/sync-3.m: New.
* obj-c++.dg/sync-3.mm: New.


Added:
trunk/gcc/testsuite/obj-c++.dg/sync-3.mm
trunk/gcc/testsuite/objc.dg/sync-3.m
Modified:
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-act.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/47118] ICE on incorrect parameter to @synchronized()

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47118

Nicola Pero  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  2010-12-30 22:07:26 
UTC ---
Fixed in trunk.

Thanks

[Bug libobjc/47173] both objc_lookUpClass and objc_lookup_class are exported symbols

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47173

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nicola at gcc dot gnu.org
 Resolution||INVALID

--- Comment #2 from Nicola Pero  2011-01-06 14:49:43 
UTC ---
Yes.  In GCC 4.6, libobjc has lots of "duplicates", because it supports both
the "Traditional" and "Modern" GNU Objective-C runtime APIs (see the GCC doc
for the explanation), which obviously overlap in functionality.

In GCC 4.7, we'll remove the traditional one and get rid of the duplicates.

The example you chose, objc_lookup_class(), is particular, though, because
objc_lookup_class() is part of the ABI too, ie, it is used by the compiler when
compiling Objective-C method invocations.  So even in GCC 4.7 we may want to
keep it around in libobjc if we want to be able to load modules compiled with
an older compiler.

Thanks

[Bug objc++/47156] obj-c++.dg/try-catch-[2|9].mm -fgnu-runtime failures

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47156

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nicola at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Nicola Pero  2011-01-06 14:54:19 
UTC ---
Thanks for the report. :-)

It's a duplicate of objc++/23616 though.

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616

Nicola Pero  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #13 from Nicola Pero  2011-01-06 
14:54:19 UTC ---
*** Bug 47156 has been marked as a duplicate of this bug. ***

[Bug objc++/35891] wrong pointer type in build_module_initializer_routine?

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35891

Nicola Pero  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #2 from Nicola Pero  2011-01-06 14:57:15 
UTC ---
No response for 3 months - closing.  I'm fairly sure it is a duplicate of
23716, already fixed.

Thanks

[Bug objc/36580] ICE at -O2 and above (with strict aliasing) with invalid Objective-C code.

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36580

Nicola Pero  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Nicola Pero  2011-01-06 14:59:44 
UTC ---
Closing - no further information / response for 3 months.

It works for me with GCC 4.6 anyway --

gcc test2.m -lobjc
test2.m:6:8: error: redefinition of ‘struct objc_class’
:0:0: note: originally defined here

with no internal compiler error :-)

Thanks

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

--- Comment #4 from Nicola Pero  2011-01-07 17:56:01 
UTC ---
Jonathan

thanks for your comments - they are very useful and we certainly want to look
at performance. ;-)

I'm not terribly convinced by using spinlocks in this context, but I'm happy to
be convinced otherwise. :-)

---

To understand what the order of magnitude is, I created a short program that
would loop and run 100m synthesized atomic, id setters.  I used GCC 4.6 to
compile, and gnustep-make/gnustep-base from trunk:

 * with the standard libobjc (objc_mutex_lock/objc_mutex_unlock), it takes
approximately 16.8 seconds to do the 100m setter calls

 * if I replace objc_mutex_lock with pthread_mutex_lock and objc_mutex_unlock
with pthread_mutex_unlock, it takes approximately 15.3 seconds (this basically
tests how fast we can go if we rework the objc_mutex... wrapper API)

 * if I comment out all the objc_mutex_lock/objc_mutex_unlock entirely, it
takes approximately 8.7 seconds.

This means that, assuming that spinlocks are infinitely faster than mutexes, in
the best possible conditions they would speed up the accessors (or, at least,
the setter, but the getter should be the same) by a maximum of about 2x. 
That's a great speedup by the way, but it's important to keep in mind that the
maximum speedup we can theoretically ever get for accessors is a 2x, not a 10x
or 100x. ;-)

---

Anyway, the key problem is that spinlocks are more wasteful (and unpredictable
?) than mutexes if there is contention and if the ratio of active threads vs.
active cores is not favourable.  Inside a kernel, when working on a specific
part, it is easy to assess these factors.  But libobjc is providing a
general-purpose, portable user-space facility for having atomic, synchronized
access to an unspecified property of an ObjC object.  It is hard to see how you
can guarantee anything about contention or ratio of active threads vs. active
cores in that context. :-(

I guess I'd feel a bit more confident if we were to experiment and benchmark
the worst-case scenario of spinlocks ... ie, how bad can they really go
compared to mutexes and how easy/hard it is for them to go bad in the case of
accessors.

Anyway, I understand you think spinlocks will always be faster than mutexes in
this case, because "My guess is that usually the spinlock is not held", but the
problem is that that is a guess, and it depends on how the accessors are used.
;-)

In particular --

 * it matters how often you call the accessors; don't forget that in the getter 
a method call (-retain) is inside the critical zone.  Even ignoring that the 
method call may trigger the execution of +initialize for the class (which would 
then execute an unbounded amount of user code into the critical zone, but which 
is fairly theoretical as the object has most likely been allocated using +alloc 
before getting a -retain, meaning +initialize should have already been done), a 
method call still constitutes about 25% of the time taken by the getter 
(ignoring locking overheads), so if your program spends 100% of the time 
calling a getter from two threads, any thread has up to a 25% chance of hitting 
the lock held by the other thread;

 * it matters how many threads you have.  If each thread spends 10% of its time 
calling a bunch of getters with the same lock, then each spends 2.5% of its 
time inside the critical zone.  If you have 2 threads, you have 2.5% of chance 
that your thread will try to enter the critical zone while the other thread is 
inside it.  But if you have 100 threads, the chances will be much much 
higher! (having 100s of threads is pretty common in server software where you 
are processing large numbers of indipendent requests simultaneously; they 
should be lightly coupled, so there is little synchronization to do; but in the 
case of synthesized property accessors, unfortunately, the locks are shared by 
completely unrelated objects, so even if the 100 threads are completely 
unrelated, as soon as they use atomic synthesized accessors, they will be using 
and competing for the same locks, exactly as if they were constantly 
synchronizing access to some shared resources!  Are spinlocks still appropriate
in this context ?)

 * it matters how many active cores you have.  If a thread tries to enter the
critical zone while another thread is holding the lock, then with mutexes it
doesn't matter if the other thread is active or suspended - there will be a
context switch in both cases; but with spinlocks it does.  If the other thread
is running on a different, active core, the first thread should waste a bit of
CPU and then enter it OK.  But if the second thread is running on the same
core, it will never make any progress during the spinning, and the first thread
will waste CPU time before being suspended - in this case it will be slower and
more CPU-wasteful than a mutex.

 * I also wonder, with all the CPUs that GCC support, if the GCC atomic
builtins a

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

--- Comment #5 from Nicola Pero  2011-01-07 18:23:10 
UTC ---
I tried the same benchmark using pthread_spin_lock() and pthread_spin_unlock();
it takes about 11.4 seconds.

So, that means the time required to execute an accessor can go down to about 
67% of the original time by using a pthread spinlock instead of 
objc_mutex_lock.  The spinlock is indeed quite fast, as locking+unlocking seems 
to take about the same time as an ObjC method call ?  That's excellent, but if 
we were to optimize objc_mutex_lock so that it's as fast as a pthread_mutex, 
then the spinlock accessor would take about 75% of the mutex accessor, so in 
the end we are reducing the accessor overhead only by 25% in the best case, 
while introducing significant unknowns for the worst case.

I guess a manual spinlock implementation could be faster than the pthread one, 
but I expect pthreads to have a good one given writing locks is the reason of 
existence of their project, so I don't expect we can do that much better than 
they do.  Still, maybe we can inline the function calls, and get it down to 10
seconds or so.

Of course, I'm testing on Linux, where IIRC uncontended mutexes are fast as
they don't actually do the kernel call unless the lock is actually already
locked.

Given that Linux is our primary target platform, the case for spinlocks does
not seem strong.  Presumably Apple uses spinlocks because their primary target
platform (Darwin) doesn't have fast mutexes in the way that Linux does ?

It would be interesting to test the worst-case scenario for spinlocks to 
complete the picture.

Thanks

[Bug libobjc/47031] libobjc uses mutexes for properties

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031

--- Comment #7 from Nicola Pero  2011-01-08 11:39:38 
UTC ---

> Usually, the lock is not held. If it is, you do a little trick: You spin 10
> times and if you still could not get the lock, it's likely the current thread
> is blocking another thread from releasing the spinlock. Again, quite unlikely,
> as the spinlock is only held for an extremely short amount of time. However,
> if it happens that after 10 spins you still could not get the lock, you call
> sched_yield() to NOT waste resources.
>
> So, in the worst case, you waste 10 spins. That's basically 10 compares. 
> That's nothing compared to a user/kernelspace switch, which is often 10 times 
> more.

Well, but locking a mutex on Linux is implemented on top of futexes and does 
not require a user/kernelspace switch unless the lock is already held (in which 
case a spinlock requires a switch too). ;-)

So, basically on Linux the standard mutexes are already optimized and perform 
not as fast but almost as fast as spinlocks in the uncontended case, but 
without the problems of spinlocks in the contented case (my benchmarks confirm 
that; there is nothing like the 10x difference you mention in the uncontented 
case). :-)

Maybe you benchmarked or used other platforms in the past; and you may have a 
very good point there.  If objc_mutex_lock() and objc_mutex_unlock() actually
do
always perform a system call each on some systems, the mutex-protected accessor 
could be so much slower (100x ?) than the spinlock-protected accessor (in the 
non-contented case) that it may make sense to multiply the number of accessor 
locks (say, to 64) to reduce the chance of contention and then use spinlocks 
there. :-)

On the other hand, mutexes are easy to port, have been ported and are known
to work well out of the box, so in terms of maintenance of other platforms I 
wouldn't mind sticking with them for all the other, less-used platforms too.  
They may not be fast, but at least they always work. ;-)

It would still be good to try a worst-case benchmark of spinlocks in the highly 
contended case.  I am assuming the performance would be really really bad, but
then I may just be wrong. ;-)

Thanks

[Bug objc/47078] [4.6 Regression] ICE on invalid type

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.08 12:07:28
   Target Milestone|--- |4.6.0
Summary|ICE on invalid type |[4.6 Regression] ICE on
   ||invalid type
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-08 12:07:28 
UTC ---
Yes, this is confirmed in GCC 4.6 (5 January 2011).  Older versions of GCC (eg,
4.0 and 4.2) seem to produce a reasonable error instead of crashing.

Thanks

[Bug objc/47078] [4.6 Regression] ICE on invalid type

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078

Nicola Pero  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Nicola Pero  2011-01-08 14:54:18 
UTC ---
I have a patch ready (testing).  A similar problem affects objc++ as well; the
patch fixes that too.

Thanks

[Bug objc/47078] [4.6 Regression] ICE on invalid type

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078

--- Comment #3 from Nicola Pero  2011-01-08 19:44:34 
UTC ---
Author: nicola
Date: Sat Jan  8 19:44:30 2011
New Revision: 168601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168601
Log:
In gcc/:
2011-01-08  Nicola Pero  

PR objc/47078
* c-parser.c (c_parser_objc_type_name): If the type is unknown,
for error recovery purposes behave as if it was not specified so
that the default type is usd.

In gcc/testsuite/:
2011-01-08  Nicola Pero  

PR objc/47078
* objc.dg/invalid-method-2.m: New.
* obj-c++.dg/invalid-method-2.mm: New.

In gcc/cp/:
2011-01-08  Nicola Pero  

PR objc/47078
* parser.c (cp_parser_objc_typename): If the type is unknown, for
error recovery purposes behave as if it was not specified so that
the default type is used.

Added:
trunk/gcc/testsuite/obj-c++.dg/invalid-method-2.mm
trunk/gcc/testsuite/objc.dg/invalid-method-2.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/47078] [4.6 Regression] ICE on invalid type

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47078

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED

--- Comment #4 from Nicola Pero  2011-01-08 19:46:16 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710

Nicola Pero  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.6.0
  Known to fail||4.6.0
   Severity|major   |critical

--- Comment #1 from Nicola Pero  2011-01-08 19:54:20 
UTC ---
This is still happening -

http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00641.html

It's very bad because from the test results it seems that the code compiles,
but then fails when executing. :-(

I asked Andreas for more information, but he couldn't provide any.

Thanks

[Bug objc/47229] Objective C and C++ compiler frontends

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47229

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  2011-01-09 12:07:57 
UTC ---
To test for an Objective-C compiler, I think you can use something like --

echo "int main (void) { return 0; }" > test.m
gcc -x objective-c test.m -o test.o

if gcc was built without objective-c support, you should get an error.

For objective-c++, you should be able to use

gcc -x objective-c++ test.m -o test.o

The advantage of doing this is that it should work with all versions of gcc
that support objective-c (and btw with other compilers as well).

Let me know if I missed the point completely! ;-)

Thanks

[Bug objc/47231] New: Commas inside ObjC method invocation can confuse compiler

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47231

   Summary: Commas inside ObjC method invocation can confuse
compiler
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


GCC accepts the invalid code

 [receiver firstArgument: a, b secondArgument: c];

and seems to (mis)compile it as if 

 [receiver firstArgument:a  secondArgument: b];

had been typed.

This is not a regression; it seems that GCC has always behaved like that (which
also suggests it's not such a high priority since nobody ever noticed or
reported it; presumably few people accidentally put commas in there).

I tried out clang 2.8, and it rejects the invalid syntax; we should improve
GCC to reject it too! ;-)

Here is a more complete testcase, with the lines that have undetected syntax
errors marked --

/* Contributed by Nicola Pero , January 2011. 
*/
/* { dg-do compile } */

@interface MyClass
- (void) method: (id)x;
- (void) method2: (id)x : (id)y;
@end

void test (MyClass *o)
{
  [o method:];  /* { dg-error "syntax error" } */
  [o method: o];/* Ok */
  [o method: o, o]; /* { dg-error "too many arguments" } */

  [o method2::];   /* { dg-error "syntax error" } */
  [o method2: o :];/* { dg-error "syntax error" } */
  [o method2: o, o :]; /* { dg-error "syntax error" } */
  [o method2: o, o :o];/* { dg-error "too many arguments" } */ /* Missing
error */
  [o method2: o:o];/* Ok */
  [o method2: o, o :o, o]; /* { dg-error "too many arguments" } */ /* Missing
error */
  [o method2: o:o, o]; /* { dg-error "too many arguments" } */
}

Thanks

[Bug objc/47232] New: Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47232

   Summary: Confusing ObjC error message "attributes may not be
specified before before ‘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 ObjC testcase:

__attribute__ ((deprecated)) @class A;

triggers the error

test5.m:1:30: error: attributes may not be specified before before ‘class’

which is clumsy.  It is due to c-parser.c producing the error "attributes may
not be specified before" which is then joined with "before 'class'".

Thanks

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47232

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.09 14:21:22
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-09 14:21:22 
UTC ---
I was looking at the other parser messages; maybe we could simply replace
"attributes may not be specified before" with "unexpected attribute".

Then, the error message would become

 unexpected attribute before 'class'

which is quite consistent with the other error messages.

Thanks

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47232

Nicola Pero  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47232

--- Comment #2 from Nicola Pero  2011-01-09 22:47:27 
UTC ---
Author: nicola
Date: Sun Jan  9 22:47:22 2011
New Revision: 168619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168619
Log:
In gcc/:
2011-01-09  Nicola Pero  

PR objc/47232
* c-parser.c (c_parser_declaration_or_fndef): Improved
error message.

In gcc/testsuite/:
2011-01-09  Nicola Pero  

PR objc/47232
* objc.dg/attributes/invalid-attribute-1.m: New.
* obj-c++.dg/attributes/invalid-attribute-1.mm: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/attributes/invalid-attribute-1.mm
trunk/gcc/testsuite/objc.dg/attributes/invalid-attribute-1.m
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/47232] Confusing ObjC error message "attributes may not be specified before before ‘class’"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47232

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2011-01-09 22:48:51 
UTC ---
Fixed in trunk (4.6.0).

Thanks

[Bug objc++/47261] New: ICE on @property declaration in the wrong place

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47261

   Summary: ICE on @property declaration in the wrong place
   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 crashes the ObjC++ compiler (it works with the ObjC one)

/* Contributed by Nicola Pero , December 2010.
 */
/* { dg-do compile } */

@interface A
{
  @property int x;
}
@end

Thanks

[Bug objc++/47261] ICE on @property declaration in the wrong place

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47261

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.11 23:17:30
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-11 23:17:30 
UTC ---
Confirmed with GCC trunk (4.6) on 11 January 2011.

Thanks

[Bug objc/47262] New: Better error message upon finding a @property in the instance variable list

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47262

   Summary: Better error message upon finding a @property in the
instance variable list
   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 error is probably fairly common --

/* Contributed by Nicola Pero , December 2010.
 */
/* { dg-do compile } */

@interface A
{
  @property int x;
}
@end

it would be nice to print a nice, friendly error message (to be defined, but
something explaining that @property should go with the methods, not instance
variables).  At the moment we print

testcase.m:6:3: error: expected specifier-qualifier-list before ‘property’

which doesn't tell an unexperienced user anything other than there is a syntax
error in the code. ;-)

Thanks

[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710

Nicola Pero  changed:

   What|Removed |Added

   Severity|critical|major

--- Comment #2 from Nicola Pero  2011-01-12 09:34:44 
UTC ---
I got access to an "ia64-unknown-linux-gnu" machine, and tried the failing 
testcases out there, but found that they are working there. :-(

Thanks

[Bug objc/47262] Better error message upon finding a @property in the instance variable list

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47262

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.12 10:24:01
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-12 10:24:01 
UTC ---
Confirmed with "gcc (GCC) 4.6.0 20110112 (experimental)".

Thanks

[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710

--- Comment #3 from Nicola Pero  2011-01-12 11:22:35 
UTC ---
I just noticed that this failure was reported on 9 January 2011, but it is no
longer reported on 10 January 2011.  What changed ?

I asked Matthias Klose if he has more information on his latest reported
failure --

http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00731.html

Thanks

[Bug objc/47231] Commas inside ObjC method invocation can confuse compiler

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47231

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.12 21:21:12
 Ever Confirmed|0   |1
  Known to fail||4.6.0

--- Comment #1 from Nicola Pero  2011-01-12 21:21:12 
UTC ---
Yes, confirmed with "gcc version 4.6.0 20110112 (experimental) (GCC)".

Thanks

[Bug objc/47314] New: Incorrect multiple selectors warning

[nicola at gcc dot gnu.org]

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 , January 2011. 
*/
/* { dg-options "-Wselector" } */
/* { dg-do compile } */

#include 

@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

[Bug objc/47314] Incorrect multiple selectors warning

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.16 13:24:03
 AssignedTo|unassigned at gcc dot   |nicola at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-01-16 13:24:03 
UTC ---
Mine; I have a patch already.

Thanks

[Bug objc/47314] Incorrect multiple selectors warning

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314

--- Comment #2 from Nicola Pero  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=gcc&view=rev&rev=168934
Log:
In gcc/objc/:
2011-01-17  Nicola Pero  

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  

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46822

Nicola Pero  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  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 ";"

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #5 from Nicola Pero  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Nicola Pero  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513

Nicola Pero  changed:

   What|Removed |Added

  Known to work||4.6.0
   Target Milestone|--- |4.6.0

[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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082

Nicola Pero  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  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47314

Nicola Pero  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  2011-01-19 02:54:56 
UTC ---
Fixed in trunk (4.6.0).

Thanks

[Bug c/22297] [4.3/4.4/4.5/4.6 Regression] missing uninitialized warning (builtin functions)

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297

Nicola Pero  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  2011-01-19 
21:40:14 UTC ---
This works for me with GCC 4.6.0 --

[nicola@lampone ~]$ cat x.c
#include 

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082

--- Comment #9 from Nicola Pero  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=gcc&view=rev&rev=169319
Log:
In gcc/:
2011-01-26  Nicola Pero  

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  
Andrew Pinski  

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082

Nicola Pero  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  2011-01-28 
00:08:01 UTC ---
Fixed in GCC trunk/4.6.0.

Thanks

[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #5 from Nicola Pero  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 objc/47682] unused-but-set-variabled warning when using fast enumeration

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47682

Nicola Pero  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  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/47784] Internal compiler error in dot notation assignment of const value

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784

Nicola Pero  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  2011-02-18 03:03:14 
UTC ---
Yes, confirmed.

Thanks

[Bug objc/47813] New: Some ObjC tests failing on ia6-suse-linux-gnu

[nicola at gcc dot gnu.org]

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784

--- Comment #2 from Nicola Pero  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/47813] Some ObjC tests failing on ia6-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.19 14:33:59
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  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:
padding struct size to alignment boundary [-Wpadded]
/ho

[Bug objc++/47711] [4.5/4.6 Regression] (even trivial) PCH fails for Objective-C++

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711

Nicola Pero  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  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813

--- Comment #2 from Nicola Pero  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++

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47711

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.3   |4.6.0

--- Comment #3 from Nicola Pero  2011-02-20 17:27:57 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/47784] Internal compiler error in dot notation assignment of const value

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784

Nicola Pero  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  2011-02-20 17:42:17 
UTC ---
Fixed in trunk.

Thanks

[Bug objc/47813] Some ObjC tests failing on ia64-suse-linux-gnu

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47813

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Nicola Pero  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/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

--- Comment #1 from Nicola Pero  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

Nicola Pero  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  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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

--- Comment #4 from Nicola Pero  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/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Nicola Pero  2011-02-22 18:31:43 
UTC ---
Resolved in trunk (4.6).

Thanks

[Bug libobjc/47922] New: [4.6 Regression] libobjc crashes with garbage collection in any real-life program

[nicola at gcc dot gnu.org]

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47922

Nicola Pero  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #1 from Nicola Pero  2011-02-28 13:13:19 
UTC ---
Fixed in trunk (4.6.0).

Thanks

[Bug libobjc/50428] New: Consider changing semantics of +initialize so that it is inherited

[nicola at gcc dot gnu.org]

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-09-16
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  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/50428] Consider changing semantics of +initialize so that it is inherited

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428

--- Comment #2 from Nicola Pero  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=gcc&view=rev&rev=179711
Log:
In libobjc/:
2011-10-08  Richard Frith-Macdonald 
Nicola Pero  

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  

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  

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

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Nicola Pero  2011-10-08 17:56:09 
UTC ---
Implemented in trunk.  The change will appear in 4.7.0.

Thanks

[Bug libobjc/49883] clang + gcc 4.6 runtime = broken

[nicola at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49883

--- Comment #2 from Nicola Pero  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=gcc&view=rev&rev=179721
Log:
In libobjc/:
2011-10-09  Nicola Pero  

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  

* 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