| |||||||||||||
GCC and static analysisGCC and static analysisPosted Apr 24, 2012 23:50 UTC (Tue) by stevenb (guest, #11536)In reply to: GCC and static analysis by jwakely Parent article: GCC and static analysis
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! ...
(Log in to post comments)
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.
|
|||||||||||||