Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
> Is the GCC compiler suite not well suited to the creation of static analysis tools?
No. I thought that was well known.
GCC and static analysis
Posted Apr 24, 2012 23:50 UTC (Tue) by stevenb (guest, #11536)
Also, this "The GIMPLE representation changes significantly from one compiler release to the next, causing a lot of things to break." argument is funny, coming from a Google developer. The only major change in the GIMPLE representation since GCC 4.0 is the change from 'everything-is-a-tree' to GIMPLE tuples. This change was mostly the work of ... Google developers!
I can't help having the impression that Google have made their own job harder by working on several branches simultaneously, instead of following the GCC trunk. It leads to what appears to be a waste of developer time (see for example http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01511.html where a Google developer hacks around a GCC 4.6 deficiency that was already fixed for GCC 4.7 in a much more comprehensive way).
Maybe Google should align their work better internally, and work more closely with the GCC community? I think that would be beneficial for both...
And for something completely different: I had so hoped that there would be a GSoC project proposal to port clang to emit GIMPLE, but alas! ...
Posted May 3, 2012 8:06 UTC (Thu) by mlopezibanez (guest, #66088)
LLVM is a much more welcoming environment than GCC. See the reaction to essentially the same patch:
The result? Clang has this warning, GCC doesn't. I think it is easy to find many examples like this.
Improving Clang/LLVM is relatively easy. Working on GCC requires incredibly amounts of knowledge, motivation, persistence and social maneuvering to get patches reviewed and approved.
One of the points that Delesley made is that the code was integrated into trunk immediately in LLVM, whereas in GCC it was languishing in a branch that would take super-human persistence during several months to get reviewed and accepted.
In fact, it is likely that Google will work less closely with GCC, as more of their engineers rely on LLVM.
Posted May 3, 2012 7:29 UTC (Thu) by mlopezibanez (guest, #66088)
* Does GCC need to concern itself with static analysis, diagnostics, modularity and all the other things where Clang excels and GCC sucks?
My opinion is that these shortcomings are producing an increasing transfer of contributors and users from GCC to LLVM, so this should be a high-priority.
Unfortunately, GCC maintainers see these things as nuisances and, at best, their answer is that people who are interested in this should do the work (without disturbing the GCC maintainers' work). But people who are interested in these features are moving to LLVM, and then working on LLVM to get the features where GCC still has some advantage (portability, optimization).
It would have been nice if the article, apart from reading what anyone could read in the mailing list, have asked some GCC global maintainers (some from google, some for suse/fedora) about their opinion on the subject and the future of GCC. Contrary to what the article says, there has been no visible wake-up call at all.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds