This is the mail archive of the gcc@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]

who owns stack args?


Consider this example (derived from gcc.c-torture/execute/920726-1.c):

  extern int a(int a, int b, int c, int d, int e, int f, const char *s1, const char *s2) __attribute__((pure));

  int
  foo()
  {
    if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi"))
      return 0;
    return 1;
  }

On rl78-elf I'm seeing a bug that only happens if a() is declared
"pure".  When the bug triggers, the address of "abc" in the second
call is *not* written to the stack.  Instead, the move is deleted by
DCE in postreload.  It's not deleted if you remove the "pure".  The
bug was exposed when strcmp() became able to increment incoming stack
arguments in-place, instead of copying them to registers.

The example was intended to reproduce the bug on intel or arm, but it
doesn't.  If there's an obvious fix for this, I'm all ears, but...

The real question is: are stack arguments call-clobbered or
call-preserved?  Does the answer depend on the "pure" attribute?


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