How to describe this bug?

Simon Marlow marlowsd at
Wed Jul 11 10:56:34 CEST 2012

On 11/07/2012 09:51, Christian Maeder wrote:
> Am 11.07.2012 10:25, schrieb Simon Marlow:
>> On 11/07/2012 08:36, Christian Maeder wrote:
>>> Hi,
>>> I think this bug is serious and should be turned into a ticket on
>>> Would you do so Sönke?
>>> The abstraction of floats (Float or Double) is broken if equality
>>> considers (random and invisible) excess bits that are not part of the
>>> ordinary sign, exponent and fraction representation.
>>> It should also hold: show f1 == show f2  => f1 == f2
>>> and: read (show f) == f
>>> (apart from NaN)
>>> Why do you "doubt that we'll ever fix this", Simon?
>> Several reasons:
>>   - the fix hurts performance badly, because you have to store floats
>>     into memory after every operation. (c.f. gcc's -ffloat-store option)
> If we sacrifice correctness for performance then we should clearly
> document this!

I will document it in the User's Guide along with the other known bugs.

>>> What is the problem to disable -fexcess-precision or enable -msse2 (on
>>> most machines) by default?
>> -fexcess-precision cannot be disabled on x86 (that is the bug).
>> -msse2 is not supported on all processors, so we can't enable it by
>> default.
> Can't "configure" find this out?

Configure will detect whether the machine you're building on supports 
-msse2, but not whether the machine that you will eventually *run* the 
code on does.  For instance, when building GHC for distribution we have 
to assume that the target machine does not support SSE2, so all the 
libraries must be built without -msse2.


> C.
>> Cheers,
>>      Simon
>>> Cheers Christian
>>> Am 10.07.2012 14:33, schrieb Simon Marlow:
>>>> On 10/07/2012 12:21, Aleksey Khudyakov wrote:
>>>>> On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn <shahn at>
>>>>> wrote:
>>>>>> I've attached the code. The code does not make direct use of
>>>>>> unsafePerformIO. It uses QuickCheck, but I don't think, this is a
>>>>>> QuickCheck bug. The used Eq-instance is the one for Float.
>>>>>> I've only managed to reproduce this bug on 32-bit-linux with
>>>>>> ghc-7.4.2
>>>>>> when compiling with -O2.
>>>>> It's expected behaviour with floats. Calculations in FPU are done in
>>>>> maximul precision available.  If one evaluation result is kept in
>>>>> registers
>>>>> and another has been moved to memory and rounded and move back to
>>>>> registers
>>>>> number will be not the same indeed.
>>>>> In short. Never compare floating point number for equality unless you
>>>>> really know
>>>>> what are you doing.
>>>> I consider it a bug, because as the original poster pointed out it is a
>>>> violation of referential transparency.  What's more, it is *not* an
>>>> inherent property of floating point arithmetic, because if the compiler
>>>> is careful to do all the operations at the correct precision then you
>>>> can get determinstic results.  This is why GHC has the
>>>> -fexcess-precision flag: you have to explicitly ask to break
>>>> referential
>>>> transparency.
>>>> The bug is that the x86 native code generator behaves as if
>>>> -fexcess-precision is always on.  I seriously doubt that we'll ever fix
>>>> this "bug": you can get correct behaviour by enabling -msse2, or
>>>> using a
>>>> 64-bit machine.  I don't off-hand know what the LLVM backend does here,
>>>> but I would guess that it has the same bug.
>>>> Cheers,
>>>>      Simon
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list