Re: GCC local variable allocation (M68K)

[Eric Smith <eric@brouhaha.com>]

"Robert J. Brown" <rj@eli.wariat.org> writes:
> I have just been working with the Gnu C++ compiler, and using inline
> member functions to return a reference to a local object is a slick
> way to implement subscripting of bitfields in memory mapped I/O device
> registers.  This technique would not work if stack space for block
> local objects were recycled the way you want.

Gross!  And non-portable!  Sure, you could do "useful" things in C using
this technique also, but that doesn't make it a good idea.  When you exit
the scope containing a local, it is a *bug* to have any reference to that
local.  Definitely in C, but even in C++, if I'm not mistaken.

> It is necessary for the compiler to generate a stack that expands for the
> duration of the file scoped function for the reference to be valid outside
> the scope of of
> the inline member function.  The locals are only reclaimed at the end
> of the outermost block that has file scope.
> I do think that there is a compiler option to make it behave the way
> you want, however.

GCC shouldn't have its defaults set up to encourage buggy code.  There
should perhaps be an option that could be set in order to make it *not*
reclaim locals at the earliest convenience.

I've written lots of code where I make variables local specifically in order
to help the compiler optimize the use of scarce resources.  This should be
the default behavior since it is predictable and portable (even if the
porting target doesn't do the same optimization).

Cheers,
Eric