Don't shoot the messenger

Don't shoot the messenger

[Eric S. Raymond]

Some people have replied to me doubting that clang has the advantages
I listed (better error messages, faster compilation, superior optimization).

I maintain a C project called GPSD which, though not above medium
size, is for various reasons a pretty good compiler-quality stress
test. I found an optimizer bug in GCC 3.x with it a few years back.

Though I normally build and test with GCC, I occasionally switch to
clang as a portability check. I also routinely use scan-build, a
clang-based auditing tool, for static code checking.

I am therefore in position to certify that the claims of better error
messages and faster compilation are by no means mere hype or
marketing. They are obviously, visibly true even under the relatively
light use I have made of the tool.

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.

Don't shoot the messenger.  I didn't create the clang problem, I'm
only reporting it in an attempt to shake up your assumptions and
concentrate your minds on how to make GCC more competitive.

You can, of course, choose to ignore or dismiss what I say.  I have a
strong suspicion that such head-in-the-sand behavior is what the clang
developers are expecting from this crew, and that is exactly why they
think they can displace GCC wthout having to say they they intend to
do so.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Both oligarch and tyrant mistrust the people, 
and therefore deprive them of arms."
	--Aristotle

Re: Don't shoot the messenger

[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: http://gcc.gnu.org/projects/tree-ssa/

Really. Do your homework.

Ciao!
Steven

Re: Don't shoot the messenger

[Eric S. Raymond]

Steven Bosscher <stevenb.gcc@gmail.com>:
> 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: http://gcc.gnu.org/projects/tree-ssa/
> 
> Really. Do your homework.
> 
> Ciao!
> Steven

And another bullet whizzes by my head.

Really, attempts to shoot the messenger *won't help*.  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.

That outcome wouldn't be a problem for me.  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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Don't shoot the messenger

[Jonathan Wakely]

On 23 January 2014 21:58, Eric S. Raymond <esr@thyrsus.com> wrote:
> Steven Bosscher <stevenb.gcc@gmail.com>:
>> 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: http://gcc.gnu.org/projects/tree-ssa/
>>
>> 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.

Re: Don't shoot the messenger

[Gregory Casamento]

Guys,

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 (http://www.gnustep.org/) and the principal author of the Gorm (Interface Builder) (http://www.gnustep.org/experience/Gorm.html) 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 http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c-in-tiobe-index.html).

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. 

Sincerely,
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 <jwakely.gcc@gmail.com> wrote:

> On 23 January 2014 21:58, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Steven Bosscher <stevenb.gcc@gmail.com>:
>>> 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: http://gcc.gnu.org/projects/tree-ssa/
>>> 
>>> 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.

Re: Don't shoot the messenger

[Eric Botcazou]

> 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
> http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c
> -in-tiobe-index.html).

I think that neither GCC nor any other compilers can reasonably compete with 
clang when it comes to Objective-C given that clang is effectively the 
reference implementation of the language through the connection with Apple.

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

Your case (implementation of Cocoa + Objective-C parser) is very specific 
though so generalizing from it alone seems a bit fast.

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

Why do you think that there is a war?  It's at most a competition between 
projects with a different focus and different strengths.

-- 
Eric Botcazou

Re: Don't shoot the messenger

[Gregory Casamento]

Eric,

On Jan 23, 2014, at 7:00 PM, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

>> 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
>> http://www.i-programmer.info/news/98-languages/4462-objective-c-overtakes-c
>> -in-tiobe-index.html).
> 
> I think that neither GCC nor any other compilers can reasonably compete with 
> clang when it comes to Objective-C given that clang is effectively the 
> reference implementation of the language through the connection with Apple.

Granted, however, at the very least GCC should consciously ramp up it’s support for Objective-C.  Currently the Objective-C implementation in GCC is woefully out of date as it doesn’t include basic support for ARC.

>> 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.
> 
> Your case (implementation of Cocoa + Objective-C parser) is very specific 
> though so generalizing from it alone seems a bit fast.

I’m not so sure about that.  My point was that GCC in general is not built in a modular fashion.  This is a shortcoming, no matter how specific, that clang doesn’t have.  The ability to use the compiler’s parser in applications outside of the compiler is an extremely powerful advantage that clang offers and is used in multiple places in clang’s own suite of software.  The static analyzer uses the parser.  On Mac OS X Xcode uses the parser to provide contextual feedback to the user while editing the source code and also uses it to colorize the source for easy reading.

So, yes, while I’m giving a very specific example what I’m referring to is an advantage.  What I can say is that something so trivial which I learned in my first course in Computer Science course at the University of Maryland where I went to school nearly 20 years ago should be reflected in GCC, yet it is not.   I found this surprising at the time I attempted to create the parser and I still do today.

>> 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.
> 
> Why do you think that there is a war?  It's at most a competition between 
> projects with a different focus and different strengths.

I wasn’t referring to a war between clang and gcc.  I was referring to the war that the FSF openly has with proprietary software.  GCC’s policies were specifically designed to prevent proprietary software from leveraging it, as stated by RMS and other people on this list.  I believe this was done because of the position of GCC at the time as the only free software compiler of any reasonable usability.   That situation has now changed and GCC can no longer rely on it’s position and be assured that it will be the most commonly used compiler on systems which promote Free Software.  I don’t believe these policies made sense then and I don’t believe they make sense now, especially given clang’s growing prominence.   I believe it is better to compete on functionality and make certain people want to use GCC because it offers more features and better features than clang, not because of any political agenda.

> -- 
> Eric Botcazou

Gregory Casamento

Re: Don't shoot the messenger

[Jonathan Wakely]

On 24 January 2014 01:02, Gregory Casamento wrote:
>
> Granted, however, at the very least GCC should consciously ramp up it’s support for Objective-C.  Currently the Objective-C implementation in GCC is woefully out of date as it doesn’t include basic support for ARC.

That's easy to say but where are the resources to do that meant to come from?

Re: Don't shoot the messenger

[Ian Lance Taylor]

On Thu, Jan 23, 2014 at 5:02 PM, Gregory Casamento
<greg.casamento@gmail.com> wrote:
>
> Granted, however, at the very least GCC should consciously ramp up it’s support for Objective-C.  Currently the Objective-C implementation in GCC is woefully out of date as it doesn’t include basic support for ARC.

I would like to see that happen, but we must be realistic.  GCC
development is driven in part by volunteers and in part by company
contributions.  There is only one large company that is interested in
Objective C: Apple.  Apple has chosen to use clang/LLVM and reject
GCC, ostensibly for licensing reasons (although personally speaking I
have to say that those arguments have not made sense to me for some
time).

It follows that all work on Objective C support in GCC will be done by
volunteers.  Most people who use Objective C naturally use clang/LLVM;
after all, it is free, and it works well.  So the volunteer pool for
Objective C in GCC is relatively small.  It is basically those people
who want or need to use Objective C and prefer to use GCC, or GPL
software in general.  There aren't very many of those people.  They've
actually done a good job in maintaining GCC's Objective C frontend.
But while I would like to see significant additions to the frontend
like ARC support, I would hesitate on planning to see it occur.

To the extent that clang/LLVM and GCC are fighting, which is not
really the case, then I think it makes sense for GCC to focus on its
strengths, not its weaknesses.  Objective C is not a strength.  I'm
not sure it makes sense for the GCC project to encourage its limited
volunteer resources to work on it.

Sorry for being blunt, but that is how I see it.

Ian

Re: Don't shoot the messenger

[Richard Kenner]

> To the extent that clang/LLVM and GCC are fighting, which is not
> really the case, then I think it makes sense for GCC to focus on its
> strengths, not its weaknesses.  Objective C is not a strength.  I'm
> not sure it makes sense for the GCC project to encourage its limited
> volunteer resources to work on it.

I agree.  Competition is a good thing.  But it's best when it's not
"head to head".  Instead each should have what it's best at.

Re: Don't shoot the messenger

[Joseph S. Myers]

On Thu, 23 Jan 2014, Eric S. Raymond wrote:

> Really, attempts to shoot the messenger *won't help*.  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.

You appear to think things are being ignored, based on a notion of FSF 
policy that is several years out of date (if it was ever accurate).

Contributions of patches to improve GCC in areas where clang has an 
advantage, such as modularity and usability as a library in editors, 
refactoring tools, static analyzers etc., are welcome and have been 
welcome for several years, at least since plugin support was added (of 
course, such tools using parts of GCC would need to be released as free 
software under GPLv3+).  See the proposed improvement projects at 
<http://gcc.gnu.org/wiki/ImprovementProjects>, and the architectural goals 
linked therefrom, for something more accurate regarding GCC developers' 
notions of current deficiencies and desired directions for GCC than an old 
notion of FSF policy.  Poorly defined interfaces, lack of modularity and 
presence of global state do not reflect some sort of policy decision; they 
reflect the history of a code base that is about twice as old as LLVM.  
Global cleanups in all these areas have been going in at least since the 
start of EGCS, and remain welcome.

Actual FSF policy is as documented at 
<http://gcc.gnu.org/gccmission.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com