Hacker News Reader

Comment by frownie | Hacker News Reader

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.

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.

The ideal scenario would be if upstream projects provided embedded test code with standardized hooks so that tests could be built, executed and results collected in an automated way.

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?

It does not necessarily have to be distro-agnostic.

Debian packages can already hook the upstream's test suite (e.g. via dh_auto_test).

From my (extremely limited and mostly dynamic language) Debian packaging experience, it seems that more often than not, packages do not use this existing hook. Not sure why that is though.

As an example, gcc generates nearly unusable code for a Via Isaiah in amd64 mode if you compile with -O1, and this has apparently been a known issue for at least 2 years.

It can be proven, see CompCert C compiler: http://compcert.inria.fr/compcert-C.html.

That only proves that a compiler behaves according to a language definition. That does not prove the executables will behave as you expect the executables to behave, and thus there is no way knowing the executables will be error free.

Frownie said error-free compilation, not error-free in all possible aspects.

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

FreeBSD can compile the kernel with Clang, but at least as of 9.0-RELEASE, the default is still GCC. They're aiming to switch to Clang for as much as possible for 10.0-RELEASE, in a couple of years.

FreeBSD has made a lot of progress with clang in the base system (which consists of both the kernel and standard userland); I run a clang-compiled FreeBSD on my laptop.

But that said, we have a lot more clang coverage through the work done by the ports team who have been running experimental builds with clang for more than a year. That work is documented here: http://wiki.freebsd.org/PortsAndClang

Isn't most of their code in Objective C? Does that use clang too?

clang does support Objective C (as does gcc).

Apple does look after a lot of plain old C (e.g. Core Foundation) and C++ (e.g. WebKit) too, so clang handles all three.

If I'm not mistaken, the drivers are also written in C++ (They used to be in Objective-C).

And? Nobody expects that gcc, or intel's reference compilers, or Microsoft's compilers produce provably correct output.

How could they? The C standard contains ambiguity in several areas.

Opps, type : : "(as far as the compilation goes)"

Reply on news.ycombinator.com