[dmd-internals] [D-Programming-Language/dmd] 48ed15: Remove import of std.random:rand from test22

[Don Clugston]

On 23 August 2011 08:59, Don Clugston <dclugston at googlemail.com> wrote:
> On 23 August 2011 00:41, Walter Bright <walter at digitalmars.com> wrote:
>>
>>
>> On 8/22/2011 3:29 PM, Don Clugston wrote:
>>>
>>> On 16 August 2011 20:08, Brad Roberts<braddr at puremagic.com>  wrote:
>>>>
>>>> On Tuesday, August 16, 2011 4:41:30 AM, Don Clugston wrote:
>>>>>
>>>>> I've added it to bugzilla.
>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=6505
>>> Walter -- are you working on fixing this?

>> The backend does spill the x87 stack when it overflows. I suspect the
>> problem may lie in the scheduler. This is easily checked by disabling the
>> scheduler and trying it.
>
> You're right, it's the scheduler. It loads 8 values on the x87 stack,
> then does fdecstp.
> Then, the 9th load lands on top of an existing value, causing a stack
> overflow exception. The loaded value gets turned into a NaN.
> I'll try to track it down further.

OK, here's the problem. The scheduler keeps track of the number of
used x87 registers via the "fpustackused" variable.
Each instruction has a "fpuadjust" value which says how many x87
registers it uses.
But, the problem is CALL instructions. They have fpuadjust = 0.
But, a function returning float returns it in ST(0) --- so fpuadjust
should be +1.
And if it's a complex result, fpuadjust should be +2.
I think it should be possible to put an assert in cgsched.c, line 2491:

            if (tbl[j])
            {
                fpu += tbl[j]->fpuadjust;
+ assert(fpu >= 0);
                if (fpu >= 8)                   // if FPU stack overflow

but this would fail at the moment, because the total goes negative
after a call followed by an FSTP.
So it needs to distinguish between each type of call, depending on how
it affects the FPU stack.
I think the bug lies in funccall() in cod1.c; it should be setting
something in 'code' to record how many x87 registers are returned.

Then, there'll be another minor problem: the number of FPU values CAN
reach 8. This is because of the code in push87() in cg87.c, which does
a
fdecstp; fstp; when the stack is full. So the condition above will
need to change to:
                if (fpu > 8)                   // if FPU stack overflow

This is too invasive a change for me to make and test.