This is the mail archive of the 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]
Other format: [Raw text]

Re: Don't shoot the messenger


I have resisted entering into this argument up until now.   All I can do here is share my experience with technical decisions that have been made in GCC.  

I am the maintainer of GNUstep ( and the principal author of the Gorm (Interface Builder) ( application as well as many other parts of GNUstep.  GNUstep, being an implementation of Cocoa, requires an up to date Objective-C compiler, something that, sadly, GCC lacks.

About 3 years ago it was necessary to have an Objective-C header parser in Gorm so that it could read classes and enter them into it's library for use when building the GUI for an application.  I attempted to use GCC's implementation, but was unable to because GCC was apparently, purposefully, not modularized such that it was possible to take advantage of the parser as a separate library.  I ended up writing my own which, while educational, should not have been necessary.   Whether the decision was made politically or not, it held back progress in my project and delayed me from adding important functionality to free software.

One other point I must make is in regards to clang's Objective-C support vs. that of GCC.   GCC regards Objective-C as a second class language and has done so for some time.  Objective-C, according to recent statistics has surpassed C++ in the number of developers using it (see this link

Clang has, in my experience, at least the above two advantages over GCC.  My project is a free software project, but, yet, we are already starting to shift towards using Clang as our primary compiler for the above two reasons among others.  It will not surprise me if I see more projects go the same way.

I can't emphasize enough how important it is to see change in GCC not just for my project's sake, but for the whole of free software.

Is it enough to "win" based on philosophical grounds, but lose on technical ones?  And if GCC loses on technical grounds aren't you, in effect, losing the war since fewer people will end up using your stuff since it doesn't do what they need or want?  I don't believe that making technical decisions on the basis of political ends really wins anything.   A message earlier in this same thread bears out that many technical decisions on GCC were, in fact, made for political reasons and that GCC should carefully consider which ones should be rescinded. 

Gregory Casamento

(Sorry for the repost, I didn’t know whether or not it was delivered as gmail sent it in HTML format which the list rejected)

On Jan 23, 2014, at 5:22 PM, Jonathan Wakely <> wrote:

> On 23 January 2014 21:58, Eric S. Raymond <> wrote:
>> Steven Bosscher <>:
>>> On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
>>>> I have not run direct checks on the quality of the optimized code, but
>>>> reports from others that it is improved seem plausible in light of
>>>> the fact that GCC's optimization technology is two decades older in
>>>> origin.
>>> Yay, another "fact".
>>> You must have missed the almost complete rewrite of GCC's optimization
>>> framework that was merged in 2004 and that's been continuously
>>> improved since than:
>>> Really. Do your homework.
>>> Ciao!
>>> Steven
>> And another bullet whizzes by my head.
>> Really, attempts to shoot the messenger *won't help*.
> Then stop trying to "help" us, please.
>> By ignoring the
>> areas where clang *does* have a clear advantage, *right now*, you are
>> displaying the exact head-in-the-sand attitude that is most likely to
>> concede the high ground to clang.
> It's not about having our head-in-the-sand and not wanting to hear the message.
> You seem to think you're doing us a favour by telling us something we
> need to hear.
> We've heard it. It's not a new message. You can stop telling us now, thanks.
>> That outcome wouldn't be a problem for me.
> In that case you can stop trying to pass on the message now. We've heard it.
>> It would hurt the FSF's
>> prestige pretty badly, though.  It's not really my job to care about that,
>> but I thought someone here would. Perhaps I was wrong.
> I know you think you're trying to help, but you're just yet another
> person standing outside the tent pissing in, thinking you're helping
> us win a war with Clang.  But there is no war.
> There's room for two high-quality open source compilers. They will
> distinguish themselves in different ways, one of which is licensing.
> Now please, stop trying to help.

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