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]

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


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