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. The fix is to get rid of the casts in the vtable initializations. Carl _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
