This is the mail archive of the
mailing list for the GCC project.
who owns stack args?
- From: DJ Delorie <dj at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 24 Feb 2016 14:20:33 -0500
- Subject: who owns stack args?
- Authentication-results: sourceware.org; auth=none
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));
if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi"))
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?