[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[csmith-dev] Fwd: Csmith TODO list



On Mon, Nov 21, 2011 at 10:15 PM, John Regehr <regehr@cs.utah.edu> wrote:
A related feature that I want: randomly fail to initialize local variables.

The thing I want to test is an invariant that the GCC, LLVM, and Valgrind people would like to provide: that for any given use of uninitialized storage, either the compiler or Valgrind complains.

Separately, warnings and Valgrind are highly unreliable.  Together, we'd like them to cover all problems.

Without further precautions, and the way I understand the philosophy behind these tools, I do not think this has the slightest chance to hold. Compilers are too false-positive-adverse and Valgrind is too, well, runtimy.

First, someone somewhere pointed out to me that GCC's warnings depend on the optimization level. I do not remember the source. Was it this mailing list? Anyway, perhaps counter-intuitively, more optimization forces the compiler to do more work, and it has more reliable warnings then. Of course, optimization prevents Valgrind to do its job properly, so you might aim at "compiler warnings with compiler optimization + Valgrind on unoptimized code" to be sound.

Then, there still is separate compilation. You might want to add "for a complete program in a single file", otherwise, it is too easy to build a counter-example:

$ cat t.c
volatile int output;

int f(void);
int g(void);

int main(){
  {
    int t[2];
    t[f()] = 12;
    output = t[f()];
  }
  {
    int t[2];
    t[g()] = 12;
    output = t[g()];
  }
}

$ gcc -c -O -Wall t.c 
t.c: In function ‘main’:
t.c:17: warning: control reaches end of non-void function
$ gcc -S -c  -Wall t.c 
t.c: In function ‘main’:
t.c:17: warning: control reaches end of non-void function
$ cat t.s
...
call f
cltq
movl $12, -16(%rbp,%rax,4)
call f
cltq
movl -16(%rbp,%rax,4), %eax
movl %eax, output(%rip)
call g
cltq
movl $12, -16(%rbp,%rax,4)
call g
cltq
movl -16(%rbp,%rax,4), %eax
movl %eax, output(%rip)
...

Linked with function f() that returns 0 every time,
and g() that returns 1 the first time and 0 the second
time, I do not think that Valgrind can warn about this
program, and gcc -Wall -O didn't warn either.

But separate compilation is a red herring. It would
fundamentally be the same with f() and g() provided in a
one-file program but depending on user input, or being
computationally expensive.

I may have missed GCC options to enable more warnings
than -Wall. This was with:
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) 

Pascal