Objective-C bugs and GCC releases

[Daniel Berlin]

On Mon, 24 Jan 2005, Gregory John Casamento wrote:

> All,
>
> I believe that since the GNUstep project is a GNU project and since both Apple
> and GNUstep current depend on GCC's ObjC frontend, that the policy of not
> considering bugs in ObjC as showstoppers needs to end.  I would like to know
> what the reasons are behind the decision this policy is.
>
> The current regressions in the ObjC compiler will make it very difficult for
> both the GNUstep project and, in my opinion, Apple to continue to use gcc
> without making modifications.   Indeed, releasing a broken ObjC compiler could
> cause a great deal damage to both the relationship of GCC with Apple and the
> GNUstep project.
>
> To my understanding a patch was submitted to correct these regressions and was
> rejected.  Links available here:
>
> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00889.html
As RTH, points out, the patch is wrong, and isn't fixing the real problem.
Patches that paper over problems instead of fixing them generally aren't 
accepted.
Maybe so if they only touched the front end, but this one doesn't.


> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01423.html
> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01516.html
>
> In one of the messages above, Zem points out that a rewrite is pending to
> correct the problem, but wont be available until 4.1.  This would mean, if I'm
> not mistaken, the the ObjC compiler in GCC will remain broken for almost a year
> before being corrected.
>
> If a rewrite is pending anyway, what's the harm in including a temporary fix in
> a front end that the GCC committee doesn't consider to be worth stopping a
> release for?

The fix isn't in the front end. It's in the generic code shared by *all* 
front ends.  Really important generic code shared by all frontends, at 
that, ie It's not some code path that rarely happens to be hit.

I'd imagine if Zem could fix the frontend problem causing the bug in the 
first place, it would be accepted.