RE: local variable alignment on Solaris/SPARC, with gcc 4.x

[laxmans at bellsouth dot net]

Hi,

Thanks for the response. I see this behavior with both 'leaf' and 'non-leaf' functions. For example, the following call tree will fail:

void testFunc2()
{
   printf("Hello\n");
}

void testFunc()
{
   char buf[10]; /* this is aligned at a 1-byte boundary */

   ... 

   testFunc2(); /* this should make it non-leaf right? */
}

int main(int argc, char* argv[])
{
   testFunc();
}

Moving the declaration of 'buf' up to main() also results in the 1-byte alignment, even with the calls to testFunc(). Am I mistaken in my interpretation of 'leaf' functions?

-Amruth

-------------- Original message from "John (Eljay) Love-Jensen" <eljay@adobe.com>: -------------- 


> Hi Amruth, 
> 
> Is someFunction() a leaf function (i.e., it does not call any other non-inlined 
> function)? 
> 
> As I understand the ABI specification, if it is a leaf function, the ABI 
> regarding alignment is not relevant. 
> 
> If it isn't a leaf function, that sounds like a compiler bug. 
> 
> >1. Has anyone else experienced the same behavior? I'd like to rule out 
> configuration issues. 
> 
> No, I use GCC 3.2 on SPARC. (Not my choice. My druthers would be to use the 
> head of the current release.) 
> 
> But I also do not write code that relies on alignment assumptions. If I have 
> alignment constraints, I'd use a union or GCC's alignment qualifier extension so 
> the constraint is explicit in the code and not assumed. 
> 
> >2. Assuming this is not a configuration issue, does anyone have information as 
> to why such a change was made? 
> 
> I assume that the change was made because the SPARC ABI does not impose stack 
> alignment on leaf functions (if the situation is a leaf function). 
> 
> I may be mistaken. 
> 
> >3. Does anyone know of any compiler options that would produce the same results 
> globally? 
> 
> No, sorry. There could be one, but I'm not familiar with it. 
> 
> But I do recommend using current release GCC 4.2.1 or at least the patched up 
> GCC 4.1.2 instead of GCC 4.1.0. 
> 
> HTH, 
> --Eljay