Hi, Carl Witty wrote: > On Fri, Feb 27, 2009 at 11:23 AM, Stefan Behnel <[email protected]> wrote: >> Also, when I compile with gcc 4.2 instead of 4.3, it just works. Stepping >> through the module init function, I noticed that gcc generates the >> assignment code in the wrong order. The second of the two statements >> >> ------------------------------- >> __pyx_vtable_4lxml_5etree__XSLTContext.__pyx_base = >> *__pyx_vtabptr_4lxml_5etree__BaseContext; >> >> *(void(**)(void))&__pyx_vtable_4lxml_5etree__XSLTContext.__pyx_base._copy >> = (void(*)(void))__pyx_f_4lxml_5etree_12_XSLTContext__copy; >> ------------------------------- >> >> ends up being executed before the first one, so that the first assignment >> overwrites the value of _copy(). Great. I also noticed that this only >> happens when I optimise with "-march=core2", while the "prescott" >> architecture works. Looks like a gcc bug to me. > > OK, I'm guessing that's actually not technically a bug. Since > __pyx_base has no components of type (void(*)(void)), an assignment to > a storage location with that type "can't possibly" interfere with an > assignment to __pyx_base (according to the ANSI C aliasing rules), and > gcc is perfectly within its rights to reorder the two.
Thanks for the explanation. > The fix is to get rid of the casts in the vtable initializations. This is now ticket #226. http://trac.cython.org/cython_trac/ticket/226 Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
