On Mon, 2011-07-18 at 21:53 +0200, Denys Duchier wrote:
Here are the diffs I used on Gentoo to test with gcc 4.6.1:
and here are the messages from the tests:
Going through the failures:
tests/plugin/options: fails because "-Wformat" is not enabled by default in my gcc, but is in yours. Minor issue.
tests/cpychecker/PyArg_ParseTuple/correct_codes_S_and_U: tests/cpychecker/PyArg_ParseTuple/correct_converter: tests/cpychecker/PyArg_ParseTuple/without_PY_SSIZE_T_CLEAN: tests/cpychecker/PyArg_ParseTuple/incorrect_codes_S_and_U: All of these are segfaulting for some reason.
tests/cpychecker/refcounts/fold_conditional: int vs Py_ssize_t issue. I seen that you're on i686. I've been doing my devel work on a 64-bit box; I think I may have accidentally assumed that a type coercion happens in this test. I'm interested in seeing what the output looks like when adding "-fdump-tree-gimple" to the gcc invocation line for that test on your machine (it should generate a file like "input.c.004t.gimple").
As for the segfaults, these are going to be more fiddly. It may be that we're running into the garbage collection issue - the plugin currently ignores the gcc garbage collection - which has merely been a theoretical problem up until now - or it could be something else.
To get a backtrace from the plugin, you need to locate the invocation line for the gcc harness, then add "-v" to the options to see the invocation of the c compiler ("cc1"). You should then be able to run it under gdb like this:
$ gdb --args FULL ARGS OF cc1 INVOCATION (gdb) run
and hopefully it will crash in a predictable, repeatable way.
(gdb) bt
There are some more notes on debugging the plugin in the README.rst
Hope this is helpful Dave