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

Brad Roberts braddr at puremagic.com
Tue Aug 23 09:55:28 PDT 2011


On Tuesday, August 23, 2011 5:46:40 AM, Don Clugston wrote:
> 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 recor
d 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.

For the time being, since this has been broken for a long time, can we 
revert/disable the failing test so that it doesn't hide other failures?


More information about the dmd-internals mailing list