| |||||||||||||
GCC and static analysisGCC and static analysisPosted Apr 24, 2012 11:29 UTC (Tue) by jwakely (subscriber, #60262)Parent article: GCC and static analysis
> The result has been a sort of wake-up call for GCC developers.
Really?
> Is the GCC compiler suite not well suited to the creation of static analysis tools?
No. I thought that was well known.
(Log in to post comments)
GCC and static analysis Posted Apr 24, 2012 23:50 UTC (Tue) by stevenb (guest, #11536) [Link]
Not really, I'd say. GIMPLE was not designed with source language level static analysis in mind.
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! ...
GCC and static analysis Posted May 3, 2012 8:06 UTC (Thu) by mlopezibanez (guest, #66088) [Link]
Blaming Google instead of reflecting on what GCC devs could have done to avoid this situation seems to be a bad strategy for keeping Google as a contributor to GCC.
LLVM is a much more welcoming environment than GCC. See the reaction to essentially the same patch:
http://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg30...
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.
GCC and static analysis Posted May 3, 2012 7:29 UTC (Thu) by mlopezibanez (guest, #66088) [Link]
Well, the article seems to miss the most important question:
* 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.
|
|||||||||||||