Re: Tracking the range of possible values for an r-value in cpychecker
On Fri, 2011-10-21 at 11:51 -0600, Tom Tromey wrote:
David> For integer types, it now uses a new WithinRange abstract
value,
David> describing the closed interval of possible values i.e.:
David> minvalue <= x <= maxvalue
It seems a shame that one cannot reuse the code tree-vrp.c for this.
It implies that you may end up rewriting many passes in Python for
similar reasons.
Agreed - though unfortunately the only thing exposed by tree-vrp.c seems
to be:
extern bool ssa_name_nonnegative_p (const_tree);
though it may be that we also get:
var = ASSERT_EXPR<>
statements added to the gimple by this pass.
I think I'm getting pulled between two goals here:
(a) writing the reference-count checker
(b) writing a more general-purpose static analyzer
The WithinRange stuff speaks to (b), and looking at tree-vrp.c, there
does seem to be a lot of overlap there (if you'll forgive the pun).
I think I need to focus back on (a) and making that work well; the
rather hokey way I've structured the checker is aimed at wrapper code,
where you have relatively simple functions that call into APIs (and leak
refcounts).
In the meantime, as of:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=e...
I've fixed up the "cpychecker" pass so that it can be run on an SSA
representation - but this isn't a real change - it still runs on the
pre-SSA representation unless you go into libcpychecker/__init__.py and
hack up the registration of the pass so that the pass is run later on.
I'm probably not familiar enough yet with all of GCC's various passes to
know where best to plug in the checker. Suggestions welcome. In
particular, I'm interested in tracking of pointer r-values, and the
l-values they point to.
I'm a little wary about moving the cpychecker pass later, though: my
understanding is that gcc's optimizations, like any good C compiler, may
make use of the fact that it's allowed to do what it likes with
undefined behaviors, and can make them do things that might be
surprising to the programmer, if it helps the machine code execute
faster for the well-defined cases. If I'm thinking this through
correctly, this seems at odds with the goals of static analysis: we're
especially interested in the undefined behaviors, and want to warn the
programmer about them. But I could be way off here.
Thoughts?
Dave