Stack space not reused

[emmanuel_attia]

Hi

I have a simple program

#include <stdio.h>

int main()
{
    {
        char buf1[2048];
        printf("buf1: %p\n", buf1);
    }
    {
        char buf2[2048];
        printf("buf2: %p\n", buf2);
    }
return 0;
}

I expect buf1 and buf2 to have the same adress since when buf2 is in scope, buf1 is out of scope.

I have tested on Visual 2010 and g++ 4.8 and I have this result:

buf1: 0035F5A0
buf2: 0035F5A0

On Intel 14.0

buf1: 002FEC80
buf2: 002FF480

In practice I have a program with lots of inlining and lots of variables accumulated on the stack and I get some 4K-aliasing penalty so I'm investigating why my code is taking so much space on stack. And I use lots of scoping to, in theory, reuse the stack the most possibly.

Is there any way to force the compiler to depop from the stack the variable out of scope ?

Regards

[KitturGanesh]

Hi Emmanuel,
Well, you're correct the compiler should effectively dispose of when variables go out of scope unless there's a reason like with optimization etc. and optimizing stack utilization is very important.

Also, there's an option to force compiler to not defer "-fno-defer-pop" popping arguments from stack. I tried this option but of no avail. Let me file this issue with our developers and I'll update this accordingly on the investigation, appreciate much.

_Kittur

[emmanuel_attia]

Is it possible to fill an issue report for this bug ? I just have reproduced it in Intel Compiler XE 15.0 (Windows)

[KitturGanesh]

Hi,

Pardon the delay in responding.. BTW, I had already filed this issue in April of this year after I responded to you. Presently, I don't see any update on the issue from the developers. What I did is to add another note in that issue that you are also able to reproduce this on the latest Intel Composer 15.0 as well and I'll increase the priority of the issue as well. I'll update you as soon as I have any update on the issue from the team. In the meantime, appreciate your patience through this.

BTW, yes you can also file an issue directly in Intel Premier Support at:  https://premier.intel.com  and attach the test case to the issue you submit there. An engineer supporting Windows product will triage the issue and can communicate with you through issue resolution as well. 

_Regards, Kittur 

[KitturGanesh]

BTW, I've raised the priority on the issue I've filed on this with the developers to high, fyi.

_Kittur 

[KitturGanesh]

Hi Emmanuel,

The latest update I have on this from our developers is that this issue be filed as a feature request as this itself is not a bug as it's an internal implementation and there's no scope based allocation of C objects. Having said that, I've filed this issue as feature request so the team can investigate and check if there's room for improving the code through scope based allocation if any. I'll update you as soon as this feature request is implemented accordingly.  In the meantime, you the best you can do is to use C++ constructors and deconstructors may be as follows:

class thing {
public:
   int *x;
   thing() { x = new int[20]; }
   ~thing() { delete x; }
}

The constructor and destructor will be called when the object goes in and out of scope. This will not directly solve your issue because you'll still may need stack allocation but this is the direction you may try.  If you can get the constructor to allocate from the stack using some code mechanism, it will allow the automatic allocation that you're looking for? Just a thought....

Thanks, Kittur.

[SergeyKostrov]

>>... >>I have tested on Visual 2010 and g++ 4.8 and I have this result: >> >>buf1: 0035F5A0 >>buf2: 0035F5A0 >> >>On Intel 14.0 >> >>buf1: 002FEC80 >>buf2: 002FF480 I think G++ v4.8 has some issues and try to verify the test-case with a latest version of GCC compiler ( 4.9.1, or 4.9.2, or so / also it makes sense to verify 32-bit and 64-bit versions of compilers ).