Re: [csmith-bugs] GCC Complaint: "init from incompatible pointer type"

[Eric Eide <eeide@cs.utah.edu>]

[tl;dr: Maybe I must use KCC to detect undef'ed behavior related to volatiles?]

Along a similar vein, Csmith generates code that leads to (Clang) warnings like
this:

	warning: initializing 'struct S0 *volatile *volatile *' with an
	expression of type 'struct S0 ***' discards qualifiers in nested
	pointer types

While I think it is (probably) true that Csmith keeps an appropriate model in
its head and thus Csmith-generated code doesn't actually do anything undefined,
the style of code that leads to the above warnings seems potentially
problematic for reduction.

It is potentially problematic because I think I would like to use warnings like
the above to weed out potentially ill-defined programs during reduction, rather
than relying on Frama-C/KCC in these cases to tell me whether or not the
program actually does something undefined.

Below is an example hand-coded program that triggers a warning like the one
above from Clang 3.2.  This example is based on the example in Question 11.10
of the C FAQ.

-----
void foo()
{
    volatile int i = 0;
    int *p;
    volatile int **q = &p; /* warning */
    *q = &i;
    *p = 1; /* undefined */
}
-----

In the above program, `p' ends up pointing to `i', so the program has undefined
behavior.  The only "compile-time symptom" of this is the warning about the
assignment of &p to q.

So if I can't weed out programs that exhibit the compile-time warnings, then my
reduction predicate will have to detect the actual undefined behavior.

Anyway, getting back to the point:

  + I can't currently do the "cheap thing" of rejecting programs based on the
    compile-time warning, because some Csmith-generated programs lead to these
    warnings "out of the box."  (Thus, if I reject programs with these
    compile-time warnings, I can't get the reduction process started.)

  + Maybe Csmith's current behavior is the right thing: "be bold, just don't
    don't do anything that is actually undefined."  But if Csmith *didn't*
    produce code that leads to warnings like the above, I could possibly write
    a faster reduction predicate.

    (Aside: I worry that Csmith might generate code like the above, but I have
    no evidence that it actually does.  Maybe its alias analysis is just much
    better than I realize.)

  + Maybe I just have to quit complaining and use KCC.  KCC is the magic
    ingredient here?

Thanks ---

Eric.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX