Very strange problem with comparing floating point numbers

[jerro]

On Monday, 1 October 2012 at 04:10:25 UTC, Ivan Agafonov wrote:
> On Sunday, 30 September 2012 at 06:20:56 UTC, jerro wrote:
>>> The second one uses fstp twice, then fld twice. I don't know, 
>>> maybe
>>> this could be a bug.
>>
>> You're right the lack of one fst/fld in the first case is a 
>> bug. x87 floating point registers are 80 bit. This:
>>
>> fstp    dword [ebp-0CH]
>>
>> Converts the value in ST0 to single precision float and stores 
>> it to memory (and pops ST0). When it is later loaded with fld, 
>> it is not the same as before storing since some precision is 
>> lost (because the D code compares floats and not reals, this 
>> is the correct behavior). In the first example, this storing 
>> and loading only happens for the first function call. For the 
>> second call the value is returned in ST0 and stays in x87 
>> registers until it is compared with fucompp so it is not 
>> truncated as the result of the first function call was. That's 
>> why the compared values are not equal.
>
> Can you or anyone report this bug? I don't know how to do this.

I'm not really sure that this is a bug anymore.  Apparently c++ 
does this like this too 
(http://www.parashift.com/c++-faq/floating-point-arith2.html). I 
do think it would be more useful if the result of floating point 
comparison would be defined in a cases like this, but for 
floating point operation in general it makes sense to keep 
intermediate results in registers. So I don't know whether 
introducing a special case for this is worth it.

If you care about this, you should probably make a thread on 
digitalmars.D, where more people will see it and comment on it.