Objective-C bugs and GCC releases

Objective-C bugs and GCC releases

[Gregory John Casamento]

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
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?

It is my opinion that the policy of allowing ObjC to be broken in releases of
GCC should stop.   While ObjC might not be as popular as C or C++ it is
certainly more widely used today than a few years ago when this decision was
apparently made.

Thanks for your kind consideration, GJC

=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A Maryland Corporation)
#### Maintainer of Gorm for GNUstep.

Re: 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.

Re: Objective-C bugs and GCC releases

[Dale Johannesen]

On Jan 24, 2005, at 2:49 PM, Daniel Berlin wrote:
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.

It looks like the code in that patch could simply be moved into the 
ObjC-specific langhook
for gimplify_expr.

Re: Objective-C bugs and GCC releases

[Richard Henderson]

On Mon, Jan 24, 2005 at 03:20:41PM -0800, Dale Johannesen wrote:
> It looks like the code in that patch could simply be moved into the 
> ObjC-specific langhook for gimplify_expr.

Possibly.  But given the amount of code in the tree optimizers
that look at types_compatible_p, I suspect that you really can't
get away with that hook continuing to return invalid data.


r~

Re: Objective-C bugs and GCC releases

[Mark Mitchell]

Gregory John Casamento wrote:

> 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?

There's no harm.  And the Objective-C maintainers are fully empowered to 
include such a fix.

> It is my opinion that the policy of allowing ObjC to be broken in releases of
> GCC should stop. 

That's up to the Objective-C maintainers to ensure.  As the RM, I will 
not hold up an otherwise good release because of Objective-C breakage.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Objective-C bugs and GCC releases

[Alex Perez]

Mark Mitchell wrote:
> Gregory John Casamento wrote:
> 
>> 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?
> 
> 
> There's no harm.  And the Objective-C maintainers are fully empowered to 
> include such a fix.
> 
>> It is my opinion that the policy of allowing ObjC to be broken in 
>> releases of
>> GCC should stop. 
> 
> 
> That's up to the Objective-C maintainers to ensure.  As the RM, I will 
> not hold up an otherwise good release because of Objective-C breakage.
> 

That's the thing, though...as far as I understand, and please, correct 
me if I am wrong, the GNUstep folk, developers, and community are not 
responsible for this lovely breakage. You're holding GNUstep, a GNU 
project, hostage to an outside corporation, Apple Computer, who surely 
has its own agenda and timetable. They can control exactly what GCC gets 
bundled with OS X. We do not have that luxury, as we can't control the 
version of GCC that gets bundled with every major distribution and BSD 
derivative. You will effectively be bending us over, and, as mentioned 
above, holding us hostage for a problem we did not create. IMHO, the 
steering committee needs to take some of the blame for their decisions, 
which have ultimately allowed this mess to occur by appointing certain 
people to certain places.

There are clearly massive personality conflicts here, which are evident 
to anyone who's been watching this increasingly-fiery exchange, which 
I'm quite proud to have had nothing to do with creating.

There are technical solutions to every problem, and except for the one 
person who actually proposed one, none of you folks, who are supposed to 
be responsible individuals, have done much to try to resolve this issue. 
It's simply degenerated to internal bickering, and bitching about how 
loosey-goosey the ObjC type system is, etc etc etc. ad infinitum.

Please, I am not a GCC hacker. I'm a normal GNUstep user, a simple open 
source project web admin, who is concerned that the actions of this 
development community threaten immediate viability of the GNUstep 
project.  Sit back for a moment and reflect on the hundreds, perhaps 
thousands, of man hours that these poor decisions may impinge upon.

I implore the GCC development community, and the Apple developers who 
checked in the code which caused these problems, (again, please correct 
me if I am wrong here, but AFAIK I am not) to examine their collective 
consciences instead of take such an impersonal and rude stance with 
regards to the dedicated GNUstep developers who work hard to make a 
product which, while you may not consider important, is considered 
important to plenty of others. Do not forget the other Objective-C 
users, such as the Swarm project (http://www.swarm.org) who may 
encounter problems if these issues are not resolved.

Hopefully, ultimately, we can all gain something from the rather 
venomous exchange which has previously ensued.

Respectfully,
Alex Perez
GNUstep.org co-maintainer
Concerned GNUstep user

P.S. I urge anyont who is reading this to respond to it in order to 
express their solidarity. Make sure it gets sent to gcc-devel and not 
just the GNUstep mailing lists, because doing the latter is merely 
preaching to the choir.

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

>> 
>> 
>> That's up to the Objective-C maintainers to ensure.  As the RM, I will not 
>> hold up an otherwise good release because of Objective-C breakage.
>> 
>
> That's the thing, though...as far as I understand, and please, correct me if 
> I am wrong, the GNUstep folk, developers, and community are not responsible 
> for this lovely breakage. You're holding GNUstep, a GNU project, hostage to 
> an outside corporation, Apple Computer, who surely has its own agenda and 
> timetable.

Whoa, nobody is holding you hostage.
You are, and continue to be, free to submit patches to objective C, or 
whatever you like.

If you are, and aren't getting reviews in a timely manner, that is a 
different issue.

>They can control exactly what GCC gets bundled with OS X. We do 
> not have that luxury, as we can't control the version of GCC that gets 
> bundled with every major distribution and BSD derivative. You will 
> effectively be bending us over, and, as mentioned above, holding us hostage 
> for a problem we did not create.

Again, nobody is holding you hostage.  You are free to submit patches. 
What isn't likely to happen however, is for people to randomly start 
fixing bugs for you, in parts of the compiler they don't have much concern 
about.

IE nobody is going to fix the objective C frontend  for you guys, 
you'll have to do it yourselves.

> some of the blame for their decisions, which have ultimately allowed this 
> mess to occur by appointing certain people to certain places.

I have not seem Zem reject a reasonable patch to fix a bug.
Can you please point me to messages (they should be in the archives) where 
Zem (or any other person you are talking about, it's hard to tell, so 
i've assumed you are referring to Zem)

>
> There are technical solutions to every problem, and except for the one person 
> who actually proposed one, none of you folks, who are supposed to be 
> responsible individuals, have done much to try to resolve this issue.

Sure they have.
RTH gave Zem (and anyone else who wanted to get this bug fixed) a path to 
fixing this the right many moons ago.


> It's 
> simply degenerated to internal bickering, and bitching about how 
> loosey-goosey the ObjC type system is, etc etc etc. ad infinitum.

Sorry, we aren't going to let people add random hacks to important places 
in the compiler, whether it be for C, C++, objective C, or 
wonderlanguage2000. We just aren't going to paper over problems.

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

>
> P.S. I urge anyont who is reading this to respond to it in order to express 
> their solidarity. Make sure it gets sent to gcc-devel and not just the 
> GNUstep mailing lists, because doing the latter is merely preaching to the 
> choir.
>
PS please don't copy lists that are moderated on cc's to gcc@gcc.gnu.org.
It's incredibly annoying to get two mails back for every reply i send, 
saying my messages are awaiting approval.

Re: Objective-C bugs and GCC releases

[Zack Weinberg]

Alex Perez <aperez@student.santarosa.edu> writes:

> Mark Mitchell wrote:
>> Gregory John Casamento wrote:
>>> It is my opinion that the policy of allowing ObjC to be broken in
>>> releases of GCC should stop.
>>
>> That's up to the Objective-C maintainers to ensure.  As the RM, I
>> will not hold up an otherwise good release because of Objective-C
>> breakage.
>> 
>
> That's the thing, though...as far as I understand, and please, correct
> me if I am wrong, the GNUstep folk, developers, and community are not
> responsible for this lovely breakage. You're holding GNUstep, a GNU
> project, hostage to an outside corporation, Apple Computer, who surely
> has its own agenda and timetable.

No, see, look.

This bug is only going to get fixed if someone decides to volunteer
their time and effort fixing it.  As it happens, someone did[1], and
so this entire discussion is in some sense moot.  But there's this
persistent misunderstanding that I want to clear up, anyway.

First off, y'all seem to be taking the position that, because a bug
has been taken off the release-critical list, that means it's never
getting fixed.  That's not what it means.  It means, when every bug
that remains on the release-critical list gets fixed, then we're going
to make the 4.0.0 release whether or not that one has been fixed yet.
However, that glorious day is still at least three months in the
future.  If someone volunteers their time and fixes some bug that's
not on the release-critical list between now and then, then that bug
too will be fixed.  In the case of the bug currently under discussion,
as I said above, this has already happened.

Second, but perhaps more important: GCC is a volunteer project just as
GNUstep, Swarm, etc. are volunteer projects.  No one has the authority
to force anyone else to sit down and write code.  Furthermore, no one
has any obligation to sit down and write code themselves.  Zem is the
ObjC maintainer, but all that means is he has the authority to decide
whether patches that have already been written, get applied, when they
affect only the ObjC front end.  It does not mean he has to use that
authority.  It does not mean he has to sit down and fix bugs himself.
He could pack up and move to Patagonia tomorrow and never communicate
with the project again, and he would not be derelict in his
obligations, because he has no obligations.  The same goes for every
other person involved in GCC development.

I appreciate that the GNUstep community has a strong interest in
getting good Objective-C compilers from the GCC community, and that
you feel we have not served you terribly well in this regard.  Well,
the cure for your pain is for you to start participating in GCC
development.  If you don't like what Apple's Objective-C people are
doing (or not doing) with the compiler, send in your own patches.
Keep doing it long enough and you'll probably get appointed
co-maintainers of the front end.

zw

[1] http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01763.html

Re: Objective-C bugs and GCC releases

[Mark Mitchell]

Zack Weinberg wrote:
> Alex Perez <aperez@student.santarosa.edu> writes:
> 
> 
>>Mark Mitchell wrote:
>>
>>>Gregory John Casamento wrote:
>>>
>>>>It is my opinion that the policy of allowing ObjC to be broken in
>>>>releases of GCC should stop.
>>>
>>>That's up to the Objective-C maintainers to ensure.  As the RM, I
>>>will not hold up an otherwise good release because of Objective-C
>>>breakage.
>>>
>>
>>That's the thing, though...as far as I understand, and please, correct
>>me if I am wrong, the GNUstep folk, developers, and community are not
>>responsible for this lovely breakage. You're holding GNUstep, a GNU
>>project, hostage to an outside corporation, Apple Computer, who surely
>>has its own agenda and timetable.
> 
> 
> No, see, look.
> 
> This bug is only going to get fixed if someone decides to volunteer
> their time and effort fixing it.

Exactly.

In fairness, the Steering Committe did however make a conscious decision 
not to designate Objective-C a release-critical language.  That is 
because there are more features in GCC (support for languages, chips, 
optimizations, etc.) than there are people to maintain them all -- 
especially to keep them all working all the time in all possible cross 
products.  So, the SC makes decisions about what to make 
release-critical.  Things that aren't release-critical can still be 
fixed -- but it's just not a priority for the release.

In this case, the SC decided that C and C++ would be the only 
release-critical languages.  That's not an indication that Ada, Fortran, 
Java, and Objective-C are inferior languages in the eyes of the SC; it's 
merely a reflection of the fact that the focus of the SC, as an agent of 
the FSF, is on making the GCC a great compiler for the GNU system and 
the Linux kernel most of which is written in C and C++.  Furthermore, 
the focus on C and C++ reflects the desires of the various Linux and 
other free operating system distributors.

As the RM, I'd be very pleased to see this, and other problems, fixed -- 
but I will not hold up the release merely because of this bug.  As 
CodeSourcery has customers that use Objective-C, I'd love to see their 
needs met.  So, I'm all for fixing the bug -- but not at the expense of 
C or C++.

I would suggest that if you are deeply interested in fixing this problem 
you do what I did when I was deeply interested in having a better free 
C++ compiler: contribute to the development of the front end you care 
about.  Or, look at the GNU Services directory to find someone you might 
be able to hire to help.

Yours,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

make header flag

[Lucaz _]

Hello everybody, I'm new here, and I just like to share an idea for gcc.
I was thinking why I need to write headers "manually", this task (most of 
times) is very mechanic.
I was talking about this here:
http://www.allegro.cc/forums/view_thread.php?_id=453021&page=0
(allegro is a i/o multiplatform free lib)

The Idea is use a flag when compiling a source to generate the header:
$gcc myfile.c -c -mkh
And it generates the myfile.o and myfile.h.

Thanks, and sorry if my idea is stupid.

Lucaz

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Objective-C bugs and GCC releases

[Patrick McFarland]

Mark Mitchell wrote:
> That's up to the Objective-C maintainers to ensure.  As the RM, I will 
> not hold up an otherwise good release because of Objective-C breakage.

Thats idiotic. Thats like saying you won't hold up the release because 
of C++ breakage.

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com
"Computer games don't affect kids; I mean if Pac-Man affected us as 
kids, we'd all be running around in darkened rooms, munching magic pills 
and listening to repetitive electronic music." -- Kristian Wilson, 
Nintendo, Inc, 1989

Re: Objective-C bugs and GCC releases

[Adrian Robert]

> In fairness, the Steering Committe did however make a conscious
> decision not to designate Objective-C a release-critical language.
> That is because there are more features in GCC (support for
> languages, chips, optimizations, etc.)  than there are people to
> maintain them all -- especially to keep them all working all the
> time in all possible cross products.

Thank you for taking the time to clarify the situation.  But..

Regardless of how you sugar-coat it, designating a language as not
release critical means in practice you can't rely on GCC going
forward for that language.  And when there are manpower shortages,
the situation is not likely to improve -- rather, the gaps that need
to be filled for support to return will increase.  The direction
things are going for GCC is to try to make it a cutting edge C/C++
compiler as you say.  But is closing that 10% or 20% gap separating
GCC from the IBM and Intel compilers really worth jettisoning entire
languages along the way?  Could there be a middle ground to holding
up releases for too long waiting for non-market-majority development
(a practice which led to the splintering of egcs in the past) on one
side and gradually but surely becoming a specialist C/C++ solution
on the other?

It might seem like that's the middle ground the SC is trying to
steer with designation of "release critical" and non-critical
languages, but I wonder if there's a better way to do it.

What about splitting gcc into two branches, a "high performance"
branch, where heavy optimization takes place, and a "completeness"
branch, where the priority is on platform and language support.
Releases come off both branches: C, C++, maybe Fortran support on
the performance branch, and all languages on the other.
Periodically, both branches are merged together for a unified
release:

   /___/      _/__
  /     \    /    \
_/       \__/      \__ ...
 \       /  \      /   ...
  \     /    \    /
   -\---      -\--
     \          \

Well, I don't know, maybe this wouldn't work in practice.. sometimes
it's only by considering the alternatives that one can become
reconciled to a situation.. ;-)

Re: Objective-C bugs and GCC releases

[Robert Dewar]

Adrian Robert wrote:

> Thank you for taking the time to clarify the situation.  But..
> 
> Regardless of how you sugar-coat it, designating a language as not
> release critical means in practice you can't rely on GCC going
> forward for that language.  And when there are manpower shortages,
> the situation is not likely to improve -- rather, the gaps that need
> to be filled for support to return will increase.  The direction
> things are going for GCC is to try to make it a cutting edge C/C++
> compiler as you say.  But is closing that 10% or 20% gap separating
> GCC from the IBM and Intel compilers really worth jettisoning entire
> languages along the way?  Could there be a middle ground to holding
> up releases for too long waiting for non-market-majority development
> (a practice which led to the splintering of egcs in the past) on one
> side and gradually but surely becoming a specialist C/C++ solution
> on the other?

I don't see the point here. Holding up the release does not somehow
make more resources available for working on Objective-C. If there
are people interested in objective-C, let them work on it. If not,
I see no basis for holding up the release.

It's the same situation with Ada. We are working away hard (really
most specifically Richard is working furiously) on getting Ada to
work for the latest GCC version. But holding up the release for
Ada would be pointless, it would not generate any more hours in the
day for Richard, and would just inconvenience other people.

Re: Objective-C bugs and GCC releases

[Mark Mitchell]

Patrick McFarland wrote:
> Mark Mitchell wrote:
> 
>> That's up to the Objective-C maintainers to ensure.  As the RM, I will 
>> not hold up an otherwise good release because of Objective-C breakage.
> 
> 
> Thats idiotic. Thats like saying you won't hold up the release because 
> of C++ breakage.

I'm not understanding your point.  (Proving your allegation of idiocy, I 
suppose.)

I would indeed hold up the release because of C++ breakage.  C++ is a 
release-critical language; Objective-C is not.  That's very much 
analagous to the fact that IA32 GNU/Linux is a release-critical 
platform; other systems like SH ELF are not.

The SC has to make some tough decisions, analagous to those that would 
be made by product management in a proprietary software development 
environment.  However, unlike that situation, there's still something 
people interested in the de-prioritized feature can do: keep it working.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Objective-C bugs and GCC releases

[Mark Mitchell]

Adrian Robert wrote:
>>In fairness, the Steering Committe did however make a conscious
>>decision not to designate Objective-C a release-critical language.
>>That is because there are more features in GCC (support for
>>languages, chips, optimizations, etc.)  than there are people to
>>maintain them all -- especially to keep them all working all the
>>time in all possible cross products.
> 
> 
> Thank you for taking the time to clarify the situation.  But..
> 
> Regardless of how you sugar-coat it, designating a language as not
> release critical means in practice you can't rely on GCC going
> forward for that language. 

I might tend to agree -- unless you actively intervene.

I see that Robert Dewar replied.  Ada is not a release-critical 
language; yet, I can assure you that AdaCore (the company Robert 
co-owns) very much expects that an Ada compiler based on GCC will exist 
for the indefinite future.  That is in part because he knows that the SC 
will not actively interfere with AdaCore working on GNU Ada (the SC 
likes to support more languages!) and also because he knows that AdaCore 
will make sufficient resources available to do the development.

It may be that the Objective-C doesn't have the resources to maintain 
the Objective-C front end.  In that case, you are probaby out of luck; 
it's unlikely that people outside your community will maintain the 
Objective-C front end gratis just to make the world a better place.  So, 
if you care about GNU Objective-C, you're going to want to organize a 
community around that language that includes some GCC developers.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Objective-C bugs and GCC releases

[Gabriel Dos Reis]

Adrian Robert <arobert@cogsci.ucsd.edu> writes:

[...]

| What about splitting gcc into two branches, a "high performance"
| branch, where heavy optimization takes place, and a "completeness"
| branch, where the priority is on platform and language support.
| Releases come off both branches: C, C++, maybe Fortran support on
| the performance branch, and all languages on the other.

IMO, that would be an effective misuse of our already limited
resources.  However, anybody is free to branch off GCC mainline.

-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net

Re: Objective-C bugs and GCC releases

[Adrian Robert]

On Jan 25, 2005, at 9:22 AM, Robert Dewar wrote:

> Adrian Robert wrote:
>
>> ...
>> Could there be a middle ground to holding
>> up releases for too long waiting for non-market-majority development
>> (a practice which led to the splintering of egcs in the past) on one
>> side and gradually but surely becoming a specialist C/C++ solution
>> on the other?
>
> I don't see the point here. Holding up the release does not somehow
> make more resources available for working on Objective-C. If there
> are people interested in objective-C, let them work on it. If not,
> I see no basis for holding up the release.

Although it's a volunteer software project, it's also a software 
project.  If broader release criteria are chosen and some of the less 
popular ones are holding up the release, those who are in a rush to 
have the release for other features, and have time, might be encouraged 
to help work on what's holding it up.  Whether that means actually 
writing code, or just being a little more tolerant and/or timely in 
providing advice and guidance to those who _are_ writing the code, it 
means getting the job done quicker.

What seems to be the issue now is that the C/C++ crowd has more 
manpower behind it, but the Objective-C crowd still thinks its language 
is important (for reasons given by other posters).  I just want to 
question the assumption that the release criteria differentiation made 
is the only possible compromise.

Re: Objective-C bugs and GCC releases

[Robert Dewar]

Adrian Robert wrote:

> Although it's a volunteer software project, it's also a software 
> project. 

And that's the reason for the decision! In terms of over all software
project goals it makes no sense to hold up the release for Objective-C
(or Ada!) Sure there are people who vitally depend on Objective-C and
Ada, but you can't meet everyone's needs at the same time. If Objective-C
is so important to some people, then they need to take steps to ensure
that more resources are placed on this language so that it is ready for
the release.

Re: Objective-C bugs and GCC releases

[Adrian Robert]

On Jan 25, 2005, at 9:29 AM, Mark Mitchell wrote:

> It may be that the Objective-C doesn't have the resources to maintain 
> the Objective-C front end.  In that case, you are probaby out of luck; 
> it's unlikely that people outside your community will maintain the 
> Objective-C front end gratis just to make the world a better place.  
> So, if you care about GNU Objective-C, you're going to want to 
> organize a community around that language that includes some GCC 
> developers.

The problem is not the nonexistence of Objective-C GCC developers, but 
their being outnumbered by the C/C++ ones (who thus determine both pace 
of development and release criteria).  Since GCC is an FSF project, I 
hope that such a path to "tyranny of the majority" can be averted.

Not because it is FSF's place to provide a warm niche for every small 
software community out there, but because a central part of the FSF's 
mission is to provide platform support for developing independence from 
proprietary software.  Objective-C and the GNUstep project based on it 
advance that goal.  Architectural and incremental performance 
improvements in gcc-4.0 (from tree-ssa, etc.), while nice to have, do 
not.  (What version of gcc does the linux kernel officially use?)

Again, I'm not suggesting a return to the days of gcc and egcs.  And 
there IS a good argument for prioritizing C/C++ support.  Just, please 
don't be so quick to preserve discontinuities in levels of support with 
these comments of "go find more developers" and "we're not going to 
wait for you".

Re: Objective-C bugs and GCC releases

[Richard Earnshaw]

On Tue, 2005-01-25 at 15:16, Adrian Robert wrote:

> What seems to be the issue now is that the C/C++ crowd has more 
> manpower behind it, but the Objective-C crowd still thinks its language 
> is important (for reasons given by other posters).  I just want to 
> question the assumption that the release criteria differentiation made 
> is the only possible compromise.

You're forgetting that this is a volunteer project.  We can't force
developers to work on something they don't want to work on.  What's
more, if we try to hold up the release for this, then those volunteers
are likely to wander off and do something else (like work on the
following release) rather than waste their own time on something of
little-to-no interest to them.

Most C/C++ developers see little interest in objective C.  If *you*
think it's important, then *you* need to find the volunteers who are
interested in doing the work (or pay someone to take an interest on your
behalf).

R.

Re: Objective-C bugs and GCC releases

[Daniel Jacobowitz]

On Tue, Jan 25, 2005 at 10:34:51AM -0500, Adrian Robert wrote:
> 
> On Jan 25, 2005, at 9:29 AM, Mark Mitchell wrote:
> 
> >It may be that the Objective-C doesn't have the resources to maintain 
> >the Objective-C front end.  In that case, you are probaby out of luck; 
> >it's unlikely that people outside your community will maintain the 
> >Objective-C front end gratis just to make the world a better place.  
> >So, if you care about GNU Objective-C, you're going to want to 
> >organize a community around that language that includes some GCC 
> >developers.
> 
> The problem is not the nonexistence of Objective-C GCC developers, but 
> their being outnumbered by the C/C++ ones (who thus determine both pace 
> of development and release criteria).

You are simply wrong on this point.  If there were more Objective-C
developers, the problem would not come up.  That's how both the Ada
and Java frontends manage.

The C/C++ GCC developers do not determine the release criteria.  The
C/C++ _users_ determine the release criteria, and the Release Manager
only codifies that.

[I am removing the GNUstep lists from the CC: because they are
moderated.  Don't copy moderated lists and public ones.]

-- 
Daniel Jacobowitz

Re: Objective-C bugs and GCC releases

[Andrew Pinski]

On Jan 25, 2005, at 11:02 AM, Daniel Jacobowitz wrote:

> On Tue, Jan 25, 2005 at 10:34:51AM -0500, Adrian Robert wrote:
>>
>> On Jan 25, 2005, at 9:29 AM, Mark Mitchell wrote:
>>
>>> It may be that the Objective-C doesn't have the resources to maintain
>>> the Objective-C front end.  In that case, you are probaby out of 
>>> luck;
>>> it's unlikely that people outside your community will maintain the
>>> Objective-C front end gratis just to make the world a better place.
>>> So, if you care about GNU Objective-C, you're going to want to
>>> organize a community around that language that includes some GCC
>>> developers.
>>
>> The problem is not the nonexistence of Objective-C GCC developers, but
>> their being outnumbered by the C/C++ ones (who thus determine both 
>> pace
>> of development and release criteria).
>
> You are simply wrong on this point.  If there were more Objective-C
> developers, the problem would not come up.  That's how both the Ada
> and Java frontends manage.

And it really does not matter now, the bug is fixed way before the
branch of the 4.0 and before the release of 4.0.

-- Pinski

Re: Objective-C bugs and GCC releases

[Helge Hess]

On Jan 25, 2005, at 16:32, Richard Earnshaw wrote:
> You're forgetting that this is a volunteer project.  We can't force
> developers to work on something they don't want to work on.

Every project has rules which need to be followed, even by volunteers. 
And in the past is was usual behaviour, if not unwritten law, not to 
break other people's stuff.
Sure, modifications are allowed, but if you change something you need 
to take care it doesn't affect other parts _of the same project_. And 
cc1obj _is_ (still?) a part of GCC.

I think thats pretty much the usual way how all projects work. Its a 
matter of fairness with the other project members.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Re: Objective-C bugs and GCC releases

[Steven Bosscher]

On Tuesday 25 January 2005 17:13, Helge Hess wrote:
> On Jan 25, 2005, at 16:32, Richard Earnshaw wrote:
> > You're forgetting that this is a volunteer project.  We can't force
> > developers to work on something they don't want to work on.
>
> Every project has rules which need to be followed, even by volunteers.
> And in the past is was usual behaviour, if not unwritten law, not to
> break other people's stuff.

Nobody broke other people's stuff.  Other people's stuff was itself
broken and it just happened to work with some luck.

> Sure, modifications are allowed, but if you change something you need
> to take care it doesn't affect other parts _of the same project_. And
> cc1obj _is_ (still?) a part of GCC.

So is C/C++, so perhaps you can convince the people pushing ObjC++
that your argument is valid.  We have already tried that without luck.

> I think thats pretty much the usual way how all projects work.

It is also how GCC works.

> Its a 
> matter of fairness with the other project members.

You seem to imply some project members treat objc unfair, but you just
so miss the point.

Gr.
Steven

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Mon, Jan 24, 2005 at 06:15:28PM -0800, Alex Perez wrote:
> That's the thing, though...as far as I understand, and please, correct 
> me if I am wrong, the GNUstep folk, developers, and community are not 
> responsible for this lovely breakage. You're holding GNUstep, a GNU 
> project, hostage to an outside corporation, Apple Computer, who surely 
> has its own agenda and timetable.

Your ill-informed accusations aren't helping your cause, as they
make GCC developers less willing to work with you.  You speak as if
there were some GCC/Apple conspiracy out to sabotage GNUstep.

If your project is impeded by bugs, please file PRs.

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Tue, Jan 25, 2005 at 06:14:03AM -0800, Adrian Robert wrote:
> Regardless of how you sugar-coat it, designating a language as not
> release critical means in practice you can't rely on GCC going
> forward for that language.

In a sense you are correct; Objective C has suffered because there are
not enough people working on it.  However, as a member of the community,
you could help to remedy that if you wished, and help to fix the bugs.

If people step up to the plate, it might just mean that 4.0.1 is the
first usable 4.x compiler for Objective-C.  If people *really* start
fixing bugs quickly, 4.0.0 might be fine (all we said is that the release
is not *waiting* for Objective C bug fixes, there would be no problem
accepting fixes).

> What about splitting gcc into two branches, a "high performance"
> branch, where heavy optimization takes place, and a "completeness"
> branch, where the priority is on platform and language support.
> Releases come off both branches: C, C++, maybe Fortran support on
> the performance branch, and all languages on the other.
> Periodically, both branches are merged together for a unified
> release:

You really don't get it.  The problem here is lack of resources, and
you're asking that *two* compilers be provided.

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Tue, Jan 25, 2005 at 10:34:51AM -0500, Adrian Robert wrote:
> The problem is not the nonexistence of Objective-C GCC developers, but 
> their being outnumbered by the C/C++ ones (who thus determine both pace 
> of development and release criteria).  Since GCC is an FSF project, I 
> hope that such a path to "tyranny of the majority" can be averted.

You are under the false impression that C and C++ users are actively
fighting Objective C.  They aren't.  Some of the technical battles in the
past have been over proposed changes that would have slowed down the
compiler for everyone, including Objective C users, and good solutions
have been found.

Re: Objective-C bugs and GCC releases

[Steven Bosscher]

On Tuesday 25 January 2005 18:39, Helge Hess wrote:
> On Jan 25, 2005, at 17:35, Steven Bosscher wrote:
> > So is C/C++, so perhaps you can convince the people pushing ObjC++
> > that your argument is valid.  We have already tried that without luck.
>
> I don't understand what you are saying. For one you seem to agree with
> me that one shall not break others code and even push that opionion
> towards ObjC++ guys, but at the same time this is done by C/C++
> contributors to ObjC.
> That doesn't seem to make a lot of sense to me.

Will you stop accusing everyone of breaking ObjC?  This is *not* what
happened.  The ObjC front end itself was broken, and not by changes to
the C/C++ front end, it was broken well before and it just happened to
work.

It is like driving in a car with a broken steering wheel.  At one point
there will be a turn and you will run off the road.  That's not because
the turn in the road should not have been there, you should just have
your car fixed.

In this case the car is the ObjC front end, and it was not fixed before
GCC took a turn.

Gr.
Steven

Re: Objective-C bugs and GCC releases

[Helge Hess]

On Jan 25, 2005, at 18:44, Steven Bosscher wrote:
> Will you stop accusing everyone of breaking ObjC?

I'm not accusing anyone. I politely asked before and got no answers 
which explained it otherwise. Just claiming that there is 
misinformation and a misunderstanding doesn't resolve issues at all.

All the information which was passed out is "the Objective-C frontend 
won't work in GCC 4.0" and as a happy cc1obj user without any issues so 
far I think it is completely valid to ask for clarification even though 
I'm not a GCC internals expert.

> This is *not* what
> happened.  The ObjC front end itself was broken, and not by changes to
> the C/C++ front end, it was broken well before and it just happened to
> work.

OK, understood your point now.

 From a user perspective it wasn't broken though, instead it was working 
just fine and behaved as expected - producing applications for 
production use at hundreds of thousands of endusers since years. So 
don't be offended, but I have a hard time to follow your "steering 
wheel" analogy.

But I suppose it isn't worth to discuss that. Am I right that the 
thread can be closed anyway because the issue is already fixed by 
Alexander Malmberg?

Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Tue, Jan 25, 2005 at 07:02:52PM +0100, Helge Hess wrote:
> All the information which was passed out is "the Objective-C frontend 
> won't work in GCC 4.0" and as a happy cc1obj user without any issues so 
> far I think it is completely valid to ask for clarification even though 
> I'm not a GCC internals expert.

No such announcement was ever made.  What Mark announced was that
Objective-C bugs would not be treated as release-critical.  What this does
is to impose a time limit on getting Objective-C bug fixes into the
compiler.  It may well be that all remaining Objective-C problems get
fixed before 4.0.0 goes out.  If not, there's still the opportunity to fix
them for 4.0.1.

Re: Objective-C bugs and GCC releases

[Stefan Strasser]

Gabriel Dos Reis schrieb:
> Adrian Robert <arobert@cogsci.ucsd.edu> writes:
> 
> [...]
> 
> | What about splitting gcc into two branches, a "high performance"
> | branch, where heavy optimization takes place, and a "completeness"
> | branch, where the priority is on platform and language support.
> | Releases come off both branches: C, C++, maybe Fortran support on
> | the performance branch, and all languages on the other.
> 

wouldn't it be better if I want to have a working compiler for language 
x to download the lastest version of gcc-x and the version of 
gcc-backend this language depends on?
I see it is not perfect to have different backends(or other parts) as 
"current release", but imho it is much better than having gcc-all 
releases with languages that don't work

and that doesn't permanently need more resources as maintaining two 
branches does.


-- 
Stefan Strasser

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

On Tue, 25 Jan 2005, Adrian Robert wrote:

>> In fairness, the Steering Committe did however make a conscious
>> decision not to designate Objective-C a release-critical language.
>> That is because there are more features in GCC (support for
>> languages, chips, optimizations, etc.)  than there are people to
>> maintain them all -- especially to keep them all working all the
>> time in all possible cross products.
>
> Thank you for taking the time to clarify the situation.  But..
>
> Regardless of how you sugar-coat it, designating a language as not
> release critical means in practice you can't rely on GCC going
> forward for that language.  And when there are manpower shortages,
> the situation is not likely to improve -- rather, the gaps that need
> to be filled for support to return will increase.

How many times does it have to be said that GCC is a volunteer project.

Regardless of how you classify objective C, release critical or not, 
people are not going to start randomly fixing objective C bugs.

The only way objective C will be up to snuff, regardless of whether it is 
classified as a release critical platform or not, is if people who care 
about it contribute patches.

It's that simple.
--Dan

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

On Tue, 25 Jan 2005, Adrian Robert wrote:

>
> On Jan 25, 2005, at 9:22 AM, Robert Dewar wrote:
>
>> Adrian Robert wrote:
>> 
>>> ...
>>> Could there be a middle ground to holding
>>> up releases for too long waiting for non-market-majority development
>>> (a practice which led to the splintering of egcs in the past) on one
>>> side and gradually but surely becoming a specialist C/C++ solution
>>> on the other?
>> 
>> I don't see the point here. Holding up the release does not somehow
>> make more resources available for working on Objective-C. If there
>> are people interested in objective-C, let them work on it. If not,
>> I see no basis for holding up the release.
>
> Although it's a volunteer software project, it's also a software project.  If 
> broader release criteria are chosen and some of the less popular ones are 
> holding up the release, those who are in a rush to have the release for other 
> features, and have time, might be encouraged to help work on what's holding 
> it up.

So in other words, you want others to do the work for you, by trying to 
hold *gcc* hostage.

> Whether that means actually writing code, or just being a little more 
> tolerant and/or timely in providing advice and guidance to those who _are_ 
> writing the code, it means getting the job done quicker.

People have been very tolerant and timely in providing advice to people 
attempting to solve objective C issues.
As has been pointed out, Richard told Zem how to fix this bug many months 
ago.

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

On Tue, 25 Jan 2005, Helge Hess wrote:

> On Jan 25, 2005, at 16:32, Richard Earnshaw wrote:
>> You're forgetting that this is a volunteer project.  We can't force
>> developers to work on something they don't want to work on.
>
> Every project has rules which need to be followed, even by volunteers. And in 
> the past is was usual behaviour, if not unwritten law, not to break other 
> people's stuff.
> Sure, modifications are allowed, but if you change something you need to take 
> care it doesn't affect other parts _of the same project_. And cc1obj _is_ 
> (still?) a part of GCC.

Zem (the objective C maintainer) broke the objective C frontend, not some 
other developer.
So your argument doesn't seem to apply, because it had nothing to do with 
something in the middle end breaking a frontend.

Re: Objective-C bugs and GCC releases

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> You are simply wrong on this point.  If there were more Objective-C
Daniel> developers, the problem would not come up.  That's how both the Ada
Daniel> and Java frontends manage.

Daniel> The C/C++ GCC developers do not determine the release criteria.  The
Daniel> C/C++ _users_ determine the release criteria, and the Release Manager
Daniel> only codifies that.

One potential problem I see with the current approach is that a
non-release-critical language can be screwed by changes outside its
purview.  For gcj we've occasionally had bugs (cf PR 19505) which
occur in the gcc core.  In theory, something like this could be
introduced the day before a release, and we'd end up shipping a broken
gcj.  No amount of manpower can solve this.

I realize this isn't the ObjC situation.

Tom

Re: Objective-C bugs and GCC releases

[Anthony Juckel]

On Tue, 25 Jan 2005 14:02:09 -0500 (EST), Daniel Berlin
<dberlin@dberlin.org> wrote:
> 
> 
> On Tue, 25 Jan 2005, Adrian Robert wrote:
> 
> >
> > On Jan 25, 2005, at 9:22 AM, Robert Dewar wrote:
> >
> >> Adrian Robert wrote:
> >>
> >>> ...
> >>> Could there be a middle ground to holding
> >>> up releases for too long waiting for non-market-majority development
> >>> (a practice which led to the splintering of egcs in the past) on one
> >>> side and gradually but surely becoming a specialist C/C++ solution
> >>> on the other?
> >>
> >> I don't see the point here. Holding up the release does not somehow
> >> make more resources available for working on Objective-C. If there
> >> are people interested in objective-C, let them work on it. If not,
> >> I see no basis for holding up the release.
> >
> > Although it's a volunteer software project, it's also a software project.  If
> > broader release criteria are chosen and some of the less popular ones are
> > holding up the release, those who are in a rush to have the release for other
> > features, and have time, might be encouraged to help work on what's holding
> > it up.
> 
> So in other words, you want others to do the work for you, by trying to
> hold *gcc* hostage.
> 
> > Whether that means actually writing code, or just being a little more
> > tolerant and/or timely in providing advice and guidance to those who _are_
> > writing the code, it means getting the job done quicker.
> 
> People have been very tolerant and timely in providing advice to people
> attempting to solve objective C issues.
> As has been pointed out, Richard told Zem how to fix this bug many months
> ago.
> 

This discussion has piqued my curiosity, so how would one interested
enough go for pointers on how to get started down the track to
grok'ing the objc frontend and how it fits into the compiler as a
whole?  Also, could anyone provide a link to the outstanding issues
with the ObjC frontend?

Anthony W. Juckel

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Tue, Jan 25, 2005 at 12:33:18PM -0700, Tom Tromey wrote:
> One potential problem I see with the current approach is that a
> non-release-critical language can be screwed by changes outside its
> purview.  For gcj we've occasionally had bugs (cf PR 19505) which
> occur in the gcc core.  In theory, something like this could be
> introduced the day before a release, and we'd end up shipping a broken
> gcj.  No amount of manpower can solve this.

We are not robots here; I know that Mark will use good judgment even if
not required to do so by what we have written down.  Should something like
that arise (a change goes in the last day that breaks Java, say), Mark can
still hold things up until the change is backed out or repaired.  However,
that can only happen if such things are caught quickly.

Re: Objective-C bugs and GCC releases

[Tom Tromey]

>>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.COM> writes:

Joe> We are not robots here; I know that Mark will use good judgment
Joe> even if not required to do so by what we have written down.
Joe> Should something like that arise (a change goes in the last day
Joe> that breaks Java, say), Mark can still hold things up until the
Joe> change is backed out or repaired.  However, that can only happen
Joe> if such things are caught quickly.

I don't mean to imply that Mark, or anybody, isn't reasonable.
And I realize the situation isn't black or white.

I'm saying, it would be nice to have some institutional assurance that
a given release won't include a serious gcj breakage... seeing those
bugs get marked "not critical" was a disturbing moment.  It would be
pretty embarrassing to have put all this work into gcj for gcc 4 only
to have it release with some silly regression like PR 19295.

Maybe this means we should try to get gcj on the release criteria
list, if only in some minimal way.  "No test suite regressions on x86
linux" is the sort of thing I'm thinking of.

Tom

Re: Objective-C bugs and GCC releases

[Patrick McFarland]

Mark Mitchell wrote:
> I would indeed hold up the release because of C++ breakage.  C++ is a 
> release-critical language; Objective-C is not.  That's very much 
> analagous to the fact that IA32 GNU/Linux is a release-critical 
> platform; other systems like SH ELF are not.

How is Objective-C not a release-critical language?

1) Quite a few people use it
2) GCC is the only useful ObjC compiler out there
3) Apple would rather not deal with GCC dev fucktardism
4) Gnustep would rather not deal with GCC dev fucktardism

> The SC has to make some tough decisions, analagous to those that would 
> be made by product management in a proprietary software development 
> environment.  However, unlike that situation, there's still something 
> people interested in the de-prioritized feature can do: keep it working.

But GCC isn't a commercial venture. It is an open source project. We 
(the open source community) don't have deadlines, we don't need to worry 
about making money. All we need to do is worry that our software isn't 
the absolute best that we can produce.

And if GCC ships with broken Objective-C, it is not the absolute best.

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com
"Computer games don't affect kids; I mean if Pac-Man affected us as 
kids, we'd all be running around in darkened rooms, munching magic pills 
and listening to repetitive electronic music." -- Kristian Wilson, 
Nintendo, Inc, 1989

Re: Objective-C bugs and GCC releases

[Joe Buck]

On Tue, Jan 25, 2005 at 05:54:44PM -0500, Patrick McFarland wrote:
> Mark Mitchell wrote:
> >I would indeed hold up the release because of C++ breakage.  C++ is a 
> >release-critical language; Objective-C is not.  That's very much 
> >analagous to the fact that IA32 GNU/Linux is a release-critical 
> >platform; other systems like SH ELF are not.
> 
> How is Objective-C not a release-critical language?
> 
> 1) Quite a few people use it
> 2) GCC is the only useful ObjC compiler out there
> 3) Apple would rather not deal with GCC dev fucktardism
> 4) Gnustep would rather not deal with GCC dev fucktardism

This list is a vehicle for the gcc developers to communicate with each
other, not for calling gcc developers insulting and obscene names.
Please stop.  If you don't, even if you aren't banned, people will just
stop reading your mail.  Trying to bludgeon people into changing their
minds by accusing them of "fucktardism" will backfire.

> But GCC isn't a commercial venture. It is an open source project. 

Well, actually it is a free software project.  Nevertheless advocates of
open source are fond of saying "release early, release often", and you
want us to release late.

> We 
> (the open source community) don't have deadlines, we don't need to worry 
> about making money. All we need to do is worry that our software isn't 
> the absolute best that we can produce.

If we do what Mark's planning on, and all goes well, then we can expect a
branch to be created very soon and a release in some small number of
months.  My guess is that there would *still* be three months from now to
fix Objective-C bugs.  If and only if the Objective-C developers can't fix
them by then would 4.0.0 have broken Objective-C.

If that's not enough time for you, then how does it serve the world to
deny everyone the new C and C++ compilers?

> And if GCC ships with broken Objective-C, it is not the absolute best.

That's what point releases are for.  Fix it in 4.0.1.

In any case, why would you expect software with a "0.0" at the end of the
name to be perfect?  Have you no experience at all?  After the release,
it's going to take some time to stabilize.  In the meantime, no one is
taking older gcc releases away from you.

Re: Objective-C bugs and GCC releases

[Steven Bosscher]

On Tuesday 25 January 2005 23:54, Patrick McFarland wrote:
> Mark Mitchell wrote:
> > I would indeed hold up the release because of C++ breakage.  C++ is a
> > release-critical language; Objective-C is not.  That's very much
> > analagous to the fact that IA32 GNU/Linux is a release-critical
> > platform; other systems like SH ELF are not.
>
> How is Objective-C not a release-critical language?
>
> 1) Quite a few people use it
> 2) GCC is the only useful ObjC compiler out there
> 3) Apple would rather not deal with GCC dev fucktardism
> 4) Gnustep would rather not deal with GCC dev fucktardism

Considering the above, it seems you should develop your own compiler
instead of filling my mail box and everyone elses with this kind of
crap.

Gr.
Steven

Re: Objective-C bugs and GCC releases

[Mike Stump]

On Jan 25, 2005, at 11:38 AM, Anthony Juckel wrote:
> This discussion has piqued my curiosity, so how would one interested
> enough go for pointers on how to get started down the track to
> grok'ing the objc frontend and how it fits into the compiler as a
> whole?

> Also, could anyone provide a link to the outstanding issues
> with the ObjC frontend?

You can look up problems in the gcc bug database.  If there are none, 
it must be perfect.  :-)  It if is perfect, then you can compile up all 
Objective-C code you can find and test it all.

 From there, I'd just start by firing up emancs, and gdb of cc1obj in 
emacs, put a breakpoint on main, and run it...  gcc -v t.m will give 
you hints on what arguments to run it with.

Beyond that, you can check out the documentation in the texi files, and 
the documentation in the code, and finally, the code itself.

Re: Objective-C bugs and GCC releases

[Nicola Pero]

> > All the information which was passed out is "the Objective-C frontend 
> > won't work in GCC 4.0" and as a happy cc1obj user without any issues so 
> > far I think it is completely valid to ask for clarification even though 
> > I'm not a GCC internals expert.
> 
> No such announcement was ever made.  What Mark announced was that
> Objective-C bugs would not be treated as release-critical.  What this does
> is to impose a time limit on getting Objective-C bug fixes into the
> compiler.

Mark should have put the spotlight on asking for help in fixing the bugs.  
This is a large mailing list of ObjC users and developers and he could 
easily get help.

Instead he chose to put the spotlight on explaining to this same large
mailing list of ObjC zealots why he doesn't care if Objective-C works or 
not when he makes a release.

Surprised that this generated a flamewar ?  I'd have been surprised of the
opposite.

Re: Objective-C bugs and GCC releases

[Steven Bosscher]

On Wednesday 26 January 2005 02:14, Nicola Pero wrote:
> This is a large mailing list of ObjC users and developers and he could
> easily get help.

Wrong.

It is cross-posted to gcc@gcc.gnu.org.  Or rather, despite
repeated attempts someone keeps re-adding the gnustep lists.

Gr.
Steven

Re: Objective-C bugs and GCC releases

[Nicola Pero]

> > This is a large mailing list of ObjC users and developers and he could
> > easily get help.
> 
> Wrong.
> 
> It is cross-posted to gcc@gcc.gnu.org.  Or rather, despite
> repeated attempts someone keeps re-adding the gnustep lists.

Are you disappointed that someone has been trying to inform ObjC users and
developers that there is a problem in the ObjC compiler and that they can
help fixing it before the next release ?

Re: Objective-C bugs and GCC releases

[Gabriel Dos Reis]

Nicola Pero <nicola@brainstorm.co.uk> writes:

| > > This is a large mailing list of ObjC users and developers and he could
| > > easily get help.
| > 
| > Wrong.
| > 
| > It is cross-posted to gcc@gcc.gnu.org.  Or rather, despite
| > repeated attempts someone keeps re-adding the gnustep lists.
| 
| Are you disappointed that someone has been trying to inform ObjC users and
| developers that there is a problem in the ObjC compiler and that they can
| help fixing it before the next release ?

I'm disappointed that a message has been sent to GCC, with a copy to
closed lists that send back spams each time one (eg. GCC maintainers)
replies to  such message.  And this is not the first time. 
That had been pointed out, but apparently it needs repeating.

-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net

Re: Objective-C bugs and GCC releases

[Mike Stump]

On Jan 25, 2005, at 5:27 PM, Nicola Pero wrote:
>>> This is a large mailing list of ObjC users and developers and he 
>>> could
>>> easily get help.
>> Wrong.
>> It is cross-posted to gcc@gcc.gnu.org.  Or rather, despite
>> repeated attempts someone keeps re-adding the gnustep lists.
> Are you disappointed that someone has been trying to inform ObjC users 
> and
> developers that there is a problem in the ObjC compiler and that they 
> can
> help fixing it before the next release ?

No, we are pissed that people put in an address that we can't email to, 
please never, ever do this.

Re: Objective-C bugs and GCC releases

[Mark Mitchell]

Nicola Pero wrote:
>>>All the information which was passed out is "the Objective-C frontend 
>>>won't work in GCC 4.0" and as a happy cc1obj user without any issues so 
>>>far I think it is completely valid to ask for clarification even though 
>>>I'm not a GCC internals expert.
>>
>>No such announcement was ever made.  What Mark announced was that
>>Objective-C bugs would not be treated as release-critical.  What this does
>>is to impose a time limit on getting Objective-C bug fixes into the
>>compiler.
> 
> 
> Mark should have put the spotlight on asking for help in fixing the bugs.  
> This is a large mailing list of ObjC users and developers and he could 
> easily get help.

I agree that I could have put a more positive spin on it: "if you will 
step in help, then we can have great Objective-C in 4.0!" rather than 
"if nothing happens, we may not have good Objective C in 4.0."  However, 
I did try to encourage people to submit patches at a couple of points.

> Instead he chose to put the spotlight on explaining to this same large
> mailing list of ObjC zealots why he doesn't care if Objective-C works or 
> not when he makes a release.

That is an overstatement.  I've never said I didn't care: only that 
Objective-C was not release-critical and that I would not hold up the 
release on account of Objective-C.

I meant exactly what I said.

I really feel about this exactly as I feel about the SH port; I'd really 
like for it to work, but if it doesn't happen, I'll go forward with the 
release.

Regards,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Objective-C bugs and GCC releases

[Nicola Pero]

> >>> This is a large mailing list of ObjC users and developers and he 
> >>> could
> >>> easily get help.
> >> Wrong.
> >> It is cross-posted to gcc@gcc.gnu.org.  Or rather, despite
> >> repeated attempts someone keeps re-adding the gnustep lists.
> > Are you disappointed that someone has been trying to inform ObjC users 
> > and
> > developers that there is a problem in the ObjC compiler and that they 
> > can
> > help fixing it before the next release ?
> 
> No, we are pissed that people put in an address that we can't email to, 
> please never, ever do this.

OK - sounds like you have a very good point here. :-)

I didn't know about this (and I imagine whoever put the mailing lists in
Cc: didn't know either).  Sorry about that then.

We still read all your posts on the other mailing lists though.

Re: Objective-C bugs and GCC releases

[Daniel Berlin]

On Wed, 26 Jan 2005, Nicola Pero wrote:

>
>>> All the information which was passed out is "the Objective-C frontend
>>> won't work in GCC 4.0" and as a happy cc1obj user without any issues so
>>> far I think it is completely valid to ask for clarification even though
>>> I'm not a GCC internals expert.
>>
>> No such announcement was ever made.  What Mark announced was that
>> Objective-C bugs would not be treated as release-critical.  What this does
>> is to impose a time limit on getting Objective-C bug fixes into the
>> compiler.
>
> Mark should have put the spotlight on asking for help in fixing the bugs.
> This is a large mailing list of ObjC users and developers and he could
> easily get help.
Actually, someone crossposted it.

> Instead he chose to put the spotlight on explaining to this same large
> mailing list of ObjC zealots why he doesn't care if Objective-C works or
> not when he makes a release.

Actually, no.
Mark didn't do that at all.
It was whoever started copying the gnustep lists that did that.
>
> Surprised that this generated a flamewar ?  I'd have been surprised of the
> opposite.
>
We try to have a couple flamewars a year, just to get in shape for our 
yearly summit.

Unfortunately, this one kinda screws us because now we can't have one till 
around March.

Re: make header flag

[James E Wilson]

Lucaz _ wrote:
> Hello everybody, I'm new here, and I just like to share an idea for gcc.
> I was thinking why I need to write headers "manually", this task (most 
> of times) is very mechanic.

It looks like this has been mostly answered in the thread you referred 
too.  It is easy enough to generate automatic prototypes, but C programs 
also contains variable declarations and definitions, defines, types, 
typedefs, etc.  You won't be able to compile a file to generate the 
prototypes unless you put all of this stuff in the .c file, but then 
once you have the .h file, some of this stuff needs to be moved over, 
and the compiler in general won't be able to know which stuff to put in 
the .h file.  Plus, once you have this stuff in the .h file, it needs to 
be removed from the .c file or else you will get duplicate definition 
errors, and you probably don't want your compiler to be editing your .c 
files behind your back.  There is too much risk that it could break 
something.

It is simpler to write the .h files by hand.  That is the way the 
language is intended to be used.

As for the prototypes, the -aux-info option will do that.  This was 
designed for the protoize program, and may not do execatly what you 
want.  You can probably get the result you want if you run the aux-info 
output through a sed/python/perl/whatever script.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com