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