[LLVMdev] qualitative comparison of correctness of llvm and gcc
John Regehr
regehr at cs.utah.edu
Sun Jul 20 14:19:55 PDT 2008
Hi folks,
We recently generated some data that seemed interesting enough to share
here. This is a comparison between compilers that ignores the
performance of the generated code and focuses only on compiler correctness.
volatile checksum
errors errors
avr-gcc-3.4 1.879% 0.378%
avr-gcc-4.1 0.037% 0.256%
avr-gcc-4.2 0.753% 0.225%
gcc-3.4 1.222% 0.004%
gcc-4.0 0.041% 0.026%
gcc-4.1 0.196% 0.024%
gcc-4.2 0.770% 0.004%
gcc-4.3 0.727% 0.003%
llvm-gcc-2.2 18.712% 0.110%
llvm-gcc-pre-2.4 0.000% 0.006%
Notes:
These numbers come from throwing 100,000 random C programs at the
various compilers. For each compiler, we compiled each test case at
-O0, -O1, -O2, -Os, and -O3 and compared the results of these
compilations. Random programs that crashed a compiler, and executables
that failed to terminate in a timely fashion, did not count towards the
100,000.
Target is ia32 except for the top three compilers, which target AVR, an
8-bit MCU. Host is Ubuntu Feisty.
A "volatile error" indicates a case where a compiler failed to respect
the volatile invariant. The volatile invariant is simply that changing
the optimization level of a strictly conforming C program must not
change the number of dynamic loads or stores to any variable that is
volatile-qualified in the compiler's input. We check this with a hacked
valgrind (for x86) or a hacked simulator (for AVR).
A "checksum error" indicates a case where changing the optimization
level of a compiler changed the computation performed by its generated
code in a way that is not correctness-preserving. The checksum is taken
over the global variables in the random program just before it terminates.
We believe that our random programs are free of unspecified and
undefined behavior (e.g. divide by zero, pointer misuse, uninitialized
variable use, dependency on order of evaluation, etc.). Therefore,
every checksum or volatile error is the result of a real compiler bug.
We can't easily prove this. However, whenever we look closely at an
apparent error, it becomes possible to legitimately blame the compiler.
I don't have handy the exact svn rev of the pre-2.4 llvm that we tested
but it's from a few weeks ago.
The improvement in llvm between 2.2 and now is no doubt the result of
many factors. I would argue that one of the most important factors was
the llvm team's rapid fixing of 5 volatile bugs and 8 code generation
bugs that we reported. We didn't test 2.3 because some bugs that we
reported were fixed before that release, some after.
Current llvm is also far harder to crash than 2.2, although we
lack statistics on this.
Since the snapshot a few weeks ago, the llvm team has fixed a few more
bugs. If this process continues it seems possible that within the
foreseeable future, llvm will be effectively free of crashes, codegen
errors, and volatile errors (for the class of random programs that we
generate).
If anyone is curious about the kinds of bugs that are found through
random testing, a list follows.
Volatile:
http://llvm.org/bugs/show_bug.cgi?id=2182
http://llvm.org/bugs/show_bug.cgi?id=2234
http://llvm.org/bugs/show_bug.cgi?id=2260
http://llvm.org/bugs/show_bug.cgi?id=2262
http://llvm.org/bugs/show_bug.cgi?id=2496
Codegen:
http://llvm.org/bugs/show_bug.cgi?id=2271
http://llvm.org/bugs/show_bug.cgi?id=2274
http://llvm.org/bugs/show_bug.cgi?id=2276
http://llvm.org/bugs/show_bug.cgi?id=2294
http://llvm.org/bugs/show_bug.cgi?id=2364
http://llvm.org/bugs/show_bug.cgi?id=2435
http://llvm.org/bugs/show_bug.cgi?id=2479
http://llvm.org/bugs/show_bug.cgi?id=2487
http://llvm.org/bugs/show_bug.cgi?id=2568
Crash/hang:
http://llvm.org/bugs/show_bug.cgi?id=2264
http://llvm.org/bugs/show_bug.cgi?id=2323
http://llvm.org/bugs/show_bug.cgi?id=2326
http://llvm.org/bugs/show_bug.cgi?id=2234
http://llvm.org/bugs/show_bug.cgi?id=2372
http://llvm.org/bugs/show_bug.cgi?id=2422
http://llvm.org/bugs/show_bug.cgi?id=2455
http://llvm.org/bugs/show_bug.cgi?id=2497
http://llvm.org/bugs/show_bug.cgi?id=2497
http://llvm.org/bugs/show_bug.cgi?id=2513
http://llvm.org/bugs/show_bug.cgi?id=2570
John Regehr
More information about the llvm-dev
mailing list