This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
A sibcall is also a leaf?!?
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Mar 2007 18:01:56 +0100
- Subject: A sibcall is also a leaf?!?
Hi Gcc gang,
Are my eyes playing tricks on me? While compiling this code:
/tmp/warn $ cat leaf.c
extern void external_func (void);
void __attribute__ ((__isr__)) foo4 (void)
{
external_func ();
return ;
}
the compiler sets current_function_is_leaf. Huh? It doesn't look very leaf-y
to me!
Thing is, I've got this "isr" attribute, which tells us things like "oops,
better save the caller-save (volatile/call_used) regs because we just entered
via an interrupt and someone was probably using them". However, I don't want
to save them unnecessarily, so I only save the call_used regs if they are
marked in regs_ever_live, /or/ if the current function is non-leaf (meaning
whatever callee it calls may clobber them).
This logic works fine - except when gcc tells me that this sibcall function
is a leaf, despite the fact that it calls out to another function that
probably clobbers the call_used regs.
The immediate solution to my situation is that I'm going to deny isr
functions in FUNCTION_OK_FOR_SIBCALL (which is the right thing to do for many
reasons), but I'm still a little bemused: is the compiler /supposed/ to
believe that a sibcall function can be a leaf?
cheers,
DaveK
--
Can't think of a witty .sigline today....