------- Comment #4 from jakub at gcc dot gnu dot org 2010-05-19 19:23 ------- Yes, it is related, but solving it in the scheduler in generic way isn't going to be trivial.
E.g. x86_64 emits memory_blockage early in ix86_expand_epilogue: /* See the comment about red zone and frame pointer usage in ix86_expand_prologue. */ if (frame_pointer_needed && frame.red_zone_size) emit_insn (gen_memory_blockage ()); Another testcase: extern void *alloca (__SIZE_TYPE__); __attribute__((noinline, noclone)) long *bar (long *p) { asm volatile ("" : : "r" (p) : "memory"); return p; } long foo (long x) { long *p = (long *) alloca (x * sizeof (long)); long *q = bar (p); return q[0]; } which shows that some blockage or preventing scheduling over the stack release is needed even when the frame size is smaller than the red zone size and that the memory address doesn't need to be obviously based on stack pointer (it would be just safe to allow moving over stack accesses that are provably in the red zone or above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199