This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Reporting GCC issues (was Re: GCC's statement expression extension)


Marc Espie wrote:
> 
> In article <3981F647.2FBFFD19@apple.com> you write:
> >Also, since they can only use Apple's modified version of
> >GCC, their complaints and problems come to us in the tools group, not to
> >bug-gcc.  So you probably haven't heard much of what they have to say.
> 
> Ouch.
> This is a very bad way to do things. This means the Apple tools group hoard
> some knowledge that may come very handy at times.

Quite true.  One of the reasons I'm at Apple is to change that, although
there is considerable inertia to overcome!  Open process was always
fairly easy at Cygnus, generally they only hired engineers who bought
into the idea to begin with.  Here you need to have concrete demonstrations
of actual benefits from the more open development process.

> There are fairly good reasons to do things that way (like, not burdening
> the main gcc development process with specific, Apple-related issues).

In practice, perhaps 90% of our user problems are related to Apple's
own changes - perhaps not surprising, since those changes have received
much less exercise and review than mainline GCC code.  (In some cases,
there is no one left at Apple who remembers the reasons for a change,
but you can't just take it out either, because the compiler dies.  Sigh.)

> One major problem gcc had in the past is lack of feedback, lack of direction:
> compiler growing and growing, with no real idea about what the userbase wanted.
> Apart from the FSF mandate, there are issues... specifically, gcc will be
> a failure if nobody uses it because of a (perceived or real) lack of
> robustness, or speed problems.

Amen!

> If you have specific instances of lots of users using some extensions over
> in the Apple's tool group, please step forward and give them to us...

I've brought up some internal issues here already, such as the embedded C++
question and overall compiler performance.  I've also encouraged other tools
engineers to forward their issues as well, although the response has been
disappointing so far - the first two got no substantive responses about the
GCC changes they proposed.  This was somewhat embarassing, since I had
sold the idea of posting proposals to the list as being an expected part
of GCC development, but the lack of response just confirmed the prevailing
internal skepticism about the value of working more closely with other GCC
developers.  (I remain optimistic though.)

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]