[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [objc-improvements] Merging back to mainline

From: David Ayers
Subject: Re: [objc-improvements] Merging back to mainline
Date: Sat, 06 Sep 2003 11:08:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Ziemowit Laski wrote:

The question that I have is therefore the following: Does the
objc-improvements-branch, in its present shape, fail to build GNUStep
or any associated apps or, if they do build, has their behavior
changed in some erroneous way? If the answer is yes, then we
should definitely fix any remaining bugs before moving forward.
But if the answer is no, I think we should go for the mainline merge.
We really can't put this off any longer if we hope to get this stuff
into the 3.4 release. Once the objc-improvements-branch fixes have
made it into the mainline, we can continue addressing the remaining

Technically, we still have strong concerns about the changed code generation due to the new assumptions the compiler makes in cases of conflicting prototypes. These should definitely should be resolved before any merge takes place.

For those not following the discussion on gnustep-discuss, the branch currently assumes IMP '(id)(*)(id)(SEL)...' for id/class typed receivers that have conflicting prototypes. The problem is that the return type could have been consistently different than id (and of a different size) with only minor conflicts in the exact class/subclass of a parameter. The old assumption would generate correct code, if these conflicts were minor. The IMP assumption could either break code generation or cause an outright compile error. Also float arguments, which often get used in OPENSTEP-like implementations, would get promoted to doubles through varadic processing. We have been discussing alternative approaches.

On the other hand we are missing a comprehensive summary of the actual additional features contained in this branch, and how they relate to the GNU runtime. Those of us, who have been working with you, have got involved more deeply through the circumstance that the branch simply didn't generate correct code for us. Through that we got /some/ idea of /some/ of the features but those have generated ... let's say mixed responses.

I understand that you have limited time and 3.4 is getting tight, but I think it's not too much to ask for a discussion of these features and especially how they relate to the GNU runtime. We were hoping to not have to burden gcc-patches or gcc lists with that discussion, and we're thankful for your efforts to potentially host an ObjC mailing list for the future (eventhough I personally would have prefered a FSF gcc hosted list, but hey, for this time around lets be as pragmatic as we can.)

But the first step would be to present the 'improvements', so may I throw the ball back in your corner :-). Personally, I'll try to be as cooperative and responsive as I can to get a consensus on how to merge these features in a meaningful way.

David Ayers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]