Re: [avr-gcc-list] When does the Stack Frame Pointer (Y) get setup?

[Bob Paddock]

> Well it's really hard to follow what you posted as you mix up your C and the 
> assembly listing.

That is right from the .lss as the compiler produced it.  Optimizing
compilers don't make easy to read code for Humans.

> I can't recreate something that I can test on my end to find out what is 
> going on.

> I noticed that you have that you're clearing the array in .init8. You have a 
> note in a comment that says that memset() should really be used instead. Have 
> you tried it with memset()?

Yes, memset does not work.  It has the same frame pointer issue.  I
posted the for() loop code sample that you can use to reproduce the
problem above the compiler .lss output.  Don already did explained the
problem, and it is what I thought it was, an oversight in the
documentation.

> For that matter, you're setting the array to all zeros. Why not just make the 
> array static? It will end up in the .bss section which gets zeroed out in the 
> startup code.

A static array would take the 128 bytes forever.  I only need them to
be filled with zeros long enough for them to be written to the EEPROM
on the first system power up (Power Up Flag set in the MCUSR
register).  It would make more sense if you saw the real code.  That
was a minimal test case that I posted that showed the problem.

>You don't have to fiddle with a .init8 section.

I'm well aware of that.  I use the .initX sections as
pseudo-constructors and the .finiX sections as pseudo-destructors.

Makes me wonder if this .initX/.finiX stuff is breaking LTO?