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?
