Add CLDouble support

The FFI spec says that we should support CLDouble, but we don't (#2793 (closed)).

Trac metadata

Trac field	Value
Version	6.10.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

mentioned in issue #2793 (closed)

changed milestone to %⊥

changed weight to 5

added Tbug Trac import labels

CLDouble is necessary for package 'convertible', which is a dependency of 'haskelldb-hdbc'. So, it's absence in GHC is a bit of a pain.

I have changed the version from 6.10.2 to 6.12.1 as it is 6.12.1 that has this problem.

Trac metadata

Trac field	Value
Version	6.10.2 → 6.12.1
TypeOfFailure	- → OtherFailure

error while compiling C2HS with GHC 6.12.1

[24 of 26] Compiling C2HS.C.Info      ( src/C2HS/C/Info.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Info.o )

src/C2HS/C/Info.hs:117:53:
    Not in scope: type constructor or class `CLDouble'

src/C2HS/C/Info.hs:142:70:
    Not in scope: type constructor or class `CLDouble'

It seems that debian/sid package has a patch for it: http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/c2hs;a=headblob;f=/patches/04_ghc6-6.12.diff

Trac metadata

Trac field	Value
CC	→ proppy@aminche.com

That's a patch for c2hs to build with a GHC which doesn't have a CLDouble type.

http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf

states that

long double == IEEE double extended, else non-IEEE wide type, else IEEE double

Long double wasn't standardised before C99 and afaik the FFI addendum doesn't specify any particular C standard to adhere to, which means that GHC (without CLDouble) right now doesn't comply with the FFI although CLDouble does not have to be quad precision.

I opt for quick re-inclusion of CLDouble, be it as quad precision or not. An alias to CDouble, or a binding to the x87's 80bit type is a perfectly ok thing to do.

CLDouble needs to be the same as the C long double type, so things don't go wrong when using the FFI with long doubles.

Replying to [ticket:3353#comment:40193 igloo]:

CLDouble needs to be the same as the C long double type, so things don't go wrong when using the FFI with long doubles.

Right, and adding a long double primitive type to GHC is not at all trivial. I thought about doing an implementation in Haskell using the FFI, but that wouldn't work because the key thing you need to be able to do with a CLDouble is pass it to a foreign function, and for that we need support in the native code generator. The primitives could be implemented using the FFI like we do for the 64-bit integral types on a 32-bit platform (although that's not entirely satisfactory).

As a workaround, code that needs CLDouble can go via a C wrapper that takes a CLDouble *. Avoid manipulating CLDouble directly in Haskell, just talk in terms of pointers to CLDouble.

Replying to [ticket:3353#comment:40193 igloo]:

CLDouble needs to be the same as the C long double type, so things don't go wrong when using the FFI with long doubles.

But there's no reliable agreement between compilers or even compiler switches on what a long double is. VS 2010 interprets it as double (96/80 bits), whereas gcc on the same will generate code for 96 bit floats on 386 and 128 bits of precision for amd64 (you can switch behaviour with -m128bit-long-double).

Implementing quad precision support doesn't fix the problem of not being able to know what a long double is without knowing the way the code to be interfaced to was compiled, whereas not providing an alias to CDouble breaks now working stuff for no reason at all.

Proper CLDouble support would either involve switches to select the proper interpretation of "long double" and explicit types for every supported bit width to interface to mixed code.

Trac metadata

Trac field	Value
CC	barsoap@web.de, proppy@aminche.com → barsoap@web.de, hackage.haskell.org@liyang.hu, proppy@aminche.com

Replying to [ticket:3353#comment:40204 simonmar]:

As a workaround, code that needs CLDouble can go via a C wrapper that takes a CLDouble *. Avoid manipulating CLDouble directly in Haskell, just talk in terms of pointers to CLDouble.

I recently had such a need, so wrote a small package to help: https://hackage.haskell.org/package/long-double

added Pnormal label