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]
Other format: [Raw text]

Don't shoot the messenger


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


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