This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug objc/45925] New objc test failures
- From: "nicola at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 7 Oct 2010 08:18:08 +0000
- Subject: [Bug objc/45925] New objc test failures
- Auto-submitted: auto-generated
- References: <bug-45925-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45925
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> 2010-10-07 08:18:03 UTC ---
Is there any way I can see the detailed logs of the failure ?
If it's the same problem that IainS reported to me privately, then it's caused
by a bug in the Apple testcases (objc-foreach-1.m etc) --
@implementation MyList
- (unsigned int)countByEnumeratingWithState:(struct __objcFastEnumerationState
*)state objects:(id *)items count:(unsigned int)stackcount
{
return 0;
}
@end
the return value should be 'long unsigned int', not 'unsigned int', and so for
'stackcount'.
What happens then is that the ObjC code generates a method call
returning/taking a 'long unsigned int', but the prototype says 'unsigned int',
and a gimplify check fails and aborts compilation.
I would imagine a fix would entail:
* having the ObjC FE check that countByEnumeratingWithState:objects:count: has
the expected method signature; if not, produce an error. The testcases would
still fail, but with an informative message rather than an internal compiler
error :-)
* fix the testcases (and add a testcase for the above error).
Thanks