Brian,

Thanks for the very clear demo program to illustrate the problem.
Is there anyone who can run look at the assembler code generated
for this demo by a recent Microsoft or Intel 'C' compiler?

In any case,
I doubt that the gcc maintainers would consider this behavior a bug.
It's been with them from before v3.3.5.  They've known about it for many
years.  They view it is an limitation of their register optimization
techniques
and are more concerned about speeding up the code than shrinking
its stack footprint.  However, for us, larger stacks = slower code due to 
stack copying and the conservative GC.

The "ugly union" solution would not be sufficient because much of the
stack is occupied by compiler generated temporaries that have no
representation in the 'C' input source.  I did consider such wholesale
code changes, but resisted because they would have been, as you say, 
quite ugly and difficult to maintain.

What I did come up with was not ugly at all.  Factor the unwieldy switch
statement of rb_eval() into separate functions to handle each node
type and clear the stack at a few opportune times.  rb_eval() becomes
smaller and more likely to be optimized.  I buried the stack clearing 
into macros that already exist.

- brent



Brian Candler wrote:
> 
> The problem can be demonstrated with a very simple program (attached), and
> it looks to me like a bug in gcc - surely it should overlap stack
> assignments for automatic variables which aren't in scope simultaneously?
> 
> One solution to rb_eval() might be an ugly union at the top of the
> function
> (second attachment). But it seems wrong to have to do this just to code
> around an implementation problem with one particular compiler, albeit a
> ubiquitous one.
> 
> Regards,
> 
> Brian.
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p20761009.html
Sent from the ruby-core mailing list archive at Nabble.com.