Opened 10 years ago

Last modified 12 months ago

#3353 new bug

Add CLDouble support

Reported by: igloo Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.12.1
Keywords: Cc: proppy@…, barsoap@…, hackage.haskell.org@…, the.dead.shall.rise@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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

Change History (12)

comment:1 Changed 9 years ago by rtvd

Type of failure: None/Unknown
Version: 6.10.26.12.1

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.

comment:2 Changed 9 years ago by guest

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'

comment:4 Changed 9 years ago by proppy

Cc: proppy@… added

comment:5 Changed 9 years ago by igloo

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

comment:6 Changed 9 years ago by ksf

Cc: barsoap@… added
patch: 0

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.

comment:7 Changed 9 years ago by 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.

comment:8 in reply to:  7 ; Changed 9 years ago by simonmar

Replying to 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.

comment:9 in reply to:  7 Changed 9 years ago by ksf

Replying to 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.

comment:10 Changed 7 years ago by liyang

Cc: hackage.haskell.org@… added

comment:11 Changed 6 years ago by refold

Cc: the.dead.shall.rise@… added

comment:12 in reply to:  8 Changed 12 months ago by claude

Replying to 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

Note: See TracTickets for help on using tickets.