> > Here is the meta-data to show that synthesized variable is no different than > none-synthesized. > I used your test case but added a user declared ivar "IAddedThisIvar" to show > this point. > > l_OBJC_$_INSTANCE_VARIABLES_Foo: > .long 32 ## 0x20 > .long 2 ## 0x2 > .quad _OBJC_IVAR_$_Foo.IAddedThisIvar > .quad L_OBJC_METH_VAR_NAME_4 > .quad L_OBJC_METH_VAR_TYPE_5 > .long 3 ## 0x3 > .long 8 ## 0x8 > .quad _OBJC_IVAR_$_Foo._window > .quad L_OBJC_METH_VAR_NAME_6 > .quad L_OBJC_METH_VAR_TYPE_5 > .long 3 ## 0x3 > .long 8 ## 0x8 >
Adding a variable makes the problem go away :) That said, it appears that the order that we're processing the implementations matters here as well and that there's no variable in Foo__. If we process the implementation of Foo before Foo__ we won't show the problem. My current thought is that we're trying to lay out Foo as part of processing the type of Foo__ and since we haven't laid out the implementation of Foo we don't know about the synthesize yet and think there aren't any variables. An earlier patch I had worked this up by looking up the implementation decl and using that as part of the layout request, but John didn't think that was correct but rather that we shouldn't be looking up the size in the non-fragile ABI. Thoughts? -eric _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
