AW: Hughe Stack Usage when having a long Initializer List

[Christoph Rüthing]

Hi,

thank you for the response. I did some further investigation and found an option that changes the behavior. Let me try to express it again correctly.

With O0 and O1 I do not see the "issue", i.e. no big chunk fo stack is allocated.
With >= O2 I see that the generated code changes to the described structure, using quite a lot of stack memory.

I also found out that -fno-schedule-insns seems to "fix" the issue to not use the big amount of stack memory.

Best Regards,
Christoph
________________________________
Von: Segher Boessenkool <segher@kernel.crashing.org>
Gesendet: Mittwoch, 5. November 2025 14:29
An: Christoph Rüthing <christoph@muppetnet.net>
Cc: gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>
Betreff: Re: Hughe Stack Usage when having a long Initializer List

Hi!

On Wed, Nov 05, 2025 at 11:33:23AM +0000, Christoph Rüthing wrote:
> today I encountered an interesting behavior of GCC for a constructor with a very long initializer list, initializing ~1000 members of different plain types like int, float, ... I see, that GCC stores basically all addresses of the members on the stack and then reads back the addresses one by one to write the initializtion values.
>
> I wonder why GCC behaves like this? For me this is useless stack usage, because it finally have pushed addresses x, x+4, x+8, ...
>
> Note: I am using GCC for ARM version 10.3.1 but we can see the behavior also in newer versions. Check the example here https://godbolt.org/z/qn9xeqvbv and you see that the Test::Test() constructor allocates 940 bytes stack and it stores just increasing addresses on the stack.
>
> Switching to -O1 or -O2 removes this behavior, I think some optimization tries to optimize the code here with the cost of quite big stack usage. Are there options that influence this behavior?

-O0 means unoptimised.  The sole goal when you use -O0 is to create
correct code, not efficient or elegant in any way.

Or did you see it with -O3 or -Os?  You didn't say.


Segher