On 10/16/20 2:46 PM, Alan Lehotsky wrote:
I’m in the process of upgrading a gcc port, but my client is using a gcc 4.4.1 port right now and has run into a scheduler bug. This seems to have been fixed at some point, as the 8.3.1 code base doesn’t seem to have the bug. But they’d like a fix on their 4.4.1 base.Basically, what I see is a block of code where we have struct pnode * pn = ctx->return_pn; atomic_write_u32((unsigned int*)&ctx->return_pn, 0); x = pn-> x; where the ‘atomic_write_u32’ is an extended asm that is basically static inline void atomic_write_u32( unsigned int *reg, unsigned int v) { asm ( "move %[dest], %[src]\n” : [dest] “=m” (*reg) : [src] “r” (v)); } What happens is that the load of the local pn gets motioned AFTER the assignment of zero to the passed in reference of ctx->return_pn, and we SEGV at runtime dereferencing a NULL pointer.
Isn't that code breaking the type-based aliasing rules? 'struct pnode *' and 'unsigned int' are not alias-compatible. does -fno-strict-aliasing resolve things? nathan -- Nathan Sidwell
