From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Tolpin <dvd@davidashen.net>
Message-Id: <200403042022.i24KMCUO059009@adat.davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 'fp: stack overflow'
In-Reply-To: <52f9c7bb60481d1c2f85c7e455ddd165@terzarima.net>
Content-Type: text/plain; charset=KOI8-R
Date: Fri,  5 Mar 2004 00:22:12 +0400
Topicbox-Message-UUID: 155bbe00-eacd-11e9-9e20-41e7f4b1d025

>
> the compiler might be miscalculating the depth of the FP
> stack, allowing it to overflow at run-time.
> (alternatively, it might just be missing a pop variant in a particular case.)
> either way it would be helpful to see if you can isolate the expression(s)
> that cause the trouble.
>

The trouble is moving all around the floating point code if I am trying
to isolate it. The expressions are moderately complex, such as

  Vtemp[i][j].x = (1.0 - t) * Vtemp[i-1][j].x + t * Vtemp[i-1][j+1].x

but the problem moves to another expression in another function or
another part of the library (or just to a later invocation of the same
function) if I simpify them.

I must admit that I do not remember the x86 assembler well enough
to debug. But it looks to me like FP stack is unbalanced, and 
gets overflowed due to missing pops (or are they called folds?)

David