11–20 of 55 posts
Looks like the most comprehensive list of differences between clang and gcc. I'm amazed. Apparently, most differences are either because clang and gcc use different standards or interpret them differently. Also, only 9% of the Debian packages have issues, meaning clang is getting more and more worth considering.
Looks like the most comprehensive list of differences between clang and gcc. I'm amazed. Apparently, most differences are either because clang and gcc use different standards or interpret them differently. Also, only 9% of the Debian packages have issues, meaning clang is getting more and more worth considering.
If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice. http://clang.debian.net/status.php?version=3.0&key=VARIA... http://clang.debian.net/status.php?version=3.0&key=NON-P...
Earlier quoted context omitted.
Doesn't Apple use clang for OS X? If it does, that's as good a validation as any for me.
Another (IMHO better) validation is that FreeBSD compiles the kernel with clang: http://wiki.freebsd.org/BuildingFreeBSDWithClang
However this doesn't proove that clang produce error-free (was afar the compiklation goes) executables.
No one can ever prove such a thing. Neither can it be proven that gcc or any compiler for that matter produces error-free executables. What this does, however, is providing information and analysis about the quality of the clang compilation process as compared to gcc.
Earlier quoted context omitted.
No one can ever prove such a thing. Neither can it be proven that gcc or any compiler for that matter produces error-free executables. What this does, however, is providing information and analysis about the quality of the clang compilation process as compared to gcc.
It can be proven, see CompCert C compiler: http://compcert.inria.fr/compcert-C.html .
Earlier quoted context omitted.
If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice. http://clang.debian.net/status.php?version=3.0&key=VARIA... http://clang.debian.net/status.php?version=3.0&key=NON-P...
What could be nice is if the error pages could suggest possible fixes for the errors that have "will never support". Might be helpful to guide bug-fixers (esp. ones that are starting out).
I was frustrated that I didn't manage to figure out how to locate the results for a given package, if there were any.
Without that, how should I (as a package upstream owner) know if I need to fix my code, or at least analyze the results with respect to my particular package?
Amazing list. I was frustrated that I didn't manage to figure out how to locate the results for a given package, if there were any. Without that, how should I (as a package upstream owner) know if I need to fix my code, or at least analyze the results with respect to my particular package?
http://clang.debian.net/logs/2012-01-12/
(I guess the ones with a 'b' appended are for clang)
Earlier quoted context omitted.
No one can ever prove such a thing. Neither can it be proven that gcc or any compiler for that matter produces error-free executables. What this does, however, is providing information and analysis about the quality of the clang compilation process as compared to gcc.
No can prove it, but at least the GCC version are actually run by people - these version and created, but never actually used. He should do some fuzz testing of these programs, with the exact same fuzz sent to the GCC versions, and then report any differences. But collecting the "results" would be hard - it's not always visible in output, you'd have to track system calls and IO.
Even if we started with a small test set for some projects, it would be a huge win in the long run just to have this scaffolding in place.
Any ideas on how to make a distro-agnostic testing hook?