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

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



Eric, 

There is a Csmith command option " "--match-exact-qualifiers"  to force
exact match of qualifiers between LHS and RHS of an assignment. Try that, it
should at least mitigate your problem.

Csmith doesn't allow "p = &q" if p is less qualified than q (the converse is
allowed). The alias analysis in Csmith does preclude the below sample code.

-Xuejun


-----Original Message-----
From: csmith-bugs-bounces@flux.utah.edu
[mailto:csmith-bugs-bounces@flux.utah.edu] On Behalf Of Eric Eide
Sent: Thursday, May 23, 2013 2:20 PM
To: Csmith Bugs Mailing List
Subject: Re: [csmith-bugs] GCC Complaint: "init from incompatible pointer
type"

[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