> Hi,
Hello,
> does anyone know how to get rid of all the "dereferencing
> type-punned pointer will break strict-aliasing rules" warnings that
> I see in the tests? I mean, except by switching them off on the gcc
> command line or passing "-fno-strict-aliasing". :)
Technically, -fno-strict-aliasing is probably your only option. You
are accessing the same memory through pointer to differently-sized
types here, and that violates the strict aliasing rules, which allows
GCC to assume that an object can only change (and thus, parts of it
may be cached in registered and such) if an object of the same size
(and nearly the same type) is written to.
The warnings may actually be real warnings that GCC has in fact
generated incorrect code. I've seen this happen before and debugging
this kind of stuff is very difficult and actually required me to
examine the assembler code in the end to see what GCC had made of my
code (and it compiled it in such a way that the caching caused off by
one errors).
> It complains about code lines where we cast public PyTypeObject
> pointers to PyObject pointers, as in the following examples:
> PyObject_Call(((PyObject*)&PyString_Type), __pyx_1, NULL);
>
> Py_INCREF(((PyObject*)&PyString_Type));
Correct, these are pointers to differently-sized types (and they are
non-const), so this causes a warning.
> and in the first two lines of the function __Pyx_PyObject_IsTrue:
>
> static INLINE int __Pyx_PyObject_IsTrue(PyObject* x) {
> if (x == Py_True) return 1;
> else if (x == Py_False) return 0;
> else return PyObject_IsTrue(x);
> }
I'm not sure why GCC is complaining here, the value is not passed on
to a function that may modify the object, only its address it used
here.
> where Python's bool header file defines Py_True as
>
> #define Py_True ((PyObject *) &_Py_TrueStruct)
>
>
> It would be nice if gcc considered PyObject and PyTypeObject
> equivalent with respect to the strict aliasing assumptions. Is there
> any way to rewrite this to make gcc a bit smarter here?
No, I don't think so. You need to compile with -fno-strict-aliasing.
In fact, Python itself is compiled with this option as well (which is
unavoidable and also necessary). Modules must be built with this
option enabled too.
It looks like distutils does NOT compile C files with this option, and
this may actually build loadable modules that break for mysterious
reasons!
> Stefan
--
With kind regards,
Sven
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
