https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856

Tom Tromey <tromey at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu.org

--- Comment #1 from Tom Tromey <tromey at gcc dot gnu.org> ---
Created attachment 36815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36815&action=edit
simple version in python

This implements the basics of the checker using the gcc python plugin.
A few notes on this:

There didn't seem to be a great way to insert __context__ into the IR.
I ended up making a const function with a special attribute.  I used a function
to
get it into the IR, const so that it would be optimized away later, and
an attribute so we could recognize it.

The attribute syntax in the test case doesn't work with gcc.  The attributes
on the function definitions can't appear at the end.

I didn't handle the version of __context__ or the attribute that takes
an explicit lock.  For __context__ this can be done (varargs function maybe);
but for the attribute I am not so sure, because I don't think the
function parameters are in scope when the attribute is parsed.  (Not sure,
maybe there's some way.)

The upstream sparse validation/context.c has a bug where _ca is declared
returning void (though this is fixed in the version attached here).

One further issue is that I chose to implement this relatively early in
the pipeline.  I did it after gimplification and after the cfg is built
(these both make it simpler to implement); but before most optimizations
are done.  This is the uninitialized warning situation again, I think,
where exactly when the pass is invoked will affect the results.  It also
brings up the question of what exactly the semantics are; for example
whether code like this is valid:

if (cond)
  lock();
blah;
if (cond)
  unlock();

This plugin will warn about this code; but maybe it should not.

Python might be too slow for your taste, but it was easy to write :) and
I think the IR and syntax issues above are problems for any approach.

Reply via email to