This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/44199] ppc64 glibc miscompilation



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]