This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: preview of the tree-check pass (Re: gcc project)
On Fri, 2006-04-07 at 01:43, Joe Buck wrote:
> On Thu, Apr 06, 2006 at 11:58:20PM +0200, Nic Volanschi wrote:
> > 3. (in the caller:) exiting the function after a va_start() then a call
> > to the mangler without an va_end().
> > This one involves more than a from/to/avoid; it is of the form
> > from/then/to/avoid. In other words, the corresponding automaton has more
> > than three states, which is the limit of my current framework. The
> > reason why I chose this limitation in the first place is to ensure taht
> > checking is linear in time and space. I'm not sure this should be
> > re-considered.
>
> The limitation is, I think, too strict. Other path-based tools (for
> example, Coverity's) handle cases like this, and limit the combinatorial
> explosion by cutting off after exploring a fixed number of paths .
Yes!, Coverity is the natural alternative (except it's not free, hum :(
). But more importantly, Coverity is (as far as I know, I didn't buy
one) a checker, not a checking compiler. Historically, it started as an
extended version of gcc, but it never tried to *remain* a compiler.
That's essential! I mean, I do not propose to transform gcc in a
standalone checking tool, but rather to add user-defined checks
*besides* normal compiling.
This is, first of all, a severe constraint: it imposes to perform checks
that take a reasonable time with respect to compiling proper (read as:
less, or even much less, time than compiling).
In turn, keeping checks efficient opens up a whole new perspective:
continuous checking. No compiler I know of is able to do this. What's
the advantage? Well, if you check your code only from time to time, you
may re-introduce bugs, or let them survive from one release to another.
To prove this point, take a look to the Linux experiment (on
mygcc.free.fr). This is the story of an old Linux (v2.4.1) that was
tested precisely with Coverity's ancestor, called MC (or xgcc, before).
Anyways, this (impressive) tool found more than 500 bugs in the OS, all
reported to the Linux developers community. Have they all disappeared? I
had the curiosity to apply mygcc to check this in a recent kernel
(2.6.13), and I found 4% surviving bugs, three years later, rephrased in
slightly different contexts. OK, 4% is not much, but if you can avoid
them, why not? And I also found 3 new bugs!
BTW, among the 12 classes of bugs found by the MC tool, 11 can be
expressed partially or completely in the much more limited setting of
mygcc (= using automata of at most 3 states). That's encouraging, isn't
it?
Well, I don't say that we should not extend the framework, due to this
experiment. We certainly should, at least for builtin checks. (gcc
passes are not all linear, are they?) However, when putting power in
user's hands, one should be very careful to two aspects:
- integrity: user checks should not hang the compiler
- performance: checks should be reasonably fast
If not, user's perception of gcc's quality may be negatively impacted,
which is quite important, I think. The direct analogy is user-space
hooks in an OS: they should not hang the whole system.
But this can be discussed further, and I encourage everyone interested
to express their feelings :°).
Nic.