Somebody claiming to be Christopher Vollick wrote:

On Fri, Feb 08, 2013 at 01:20:53PM +0100, Gabor Greif wrote:

...

libraries/base/Foreign/C/Types.hs:162:72: No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Fractional CFloat)

Has anybody seen this with HEAD?

This may be a side effect of the fix for http://hackage.haskell.org/trac/ghc/ticket/7569 -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Okay, here is a compile-time check whether a C type is float or integral: cat <<EOF > detect-float-compile-time.c typedef char testarray_f[(float)0.4 - (float)0.8 < 0 ? 1 : -1]; typedef char testarray_d[(double)0.4 - (double)0.8 < 0 ? 1 : -1]; typedef char testarray_x[(long double)0.4 - (long double)0.8 < 0 ? 1 : -1]; typedef char testarray_i[(int)0.4 - (int)0.8 < 0 ? 1 : -1]; EOF $ gcc detect-float-compile-time.c -c -o /dev/null detect-float-compile-time.c:4: error: size of array ‘testarray_i’ is negative Note that the fourth line errored out, since 'int' is not a float type. This test should be robust enough for any cross target. I'll try to fix the configury tomorrow and submit a patch. Cheers, Gabor On 2/8/13, Gabor Greif wrote:

On 2/8/13, Stephen Paul Weber wrote:

...

Somebody claiming to be Christopher Vollick wrote:

...

On Fri, Feb 08, 2013 at 01:20:53PM +0100, Gabor Greif wrote:

...

libraries/base/Foreign/C/Types.hs:162:72: No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Fractional CFloat)

Has anybody seen this with HEAD?

This may be a side effect of the fix for http://hackage.haskell.org/trac/ghc/ticket/7569

Yeah, something with the test that contains the literal double 1.4 When configure runs, it does not succeed to set HTYPE_IS_INTEGRAL to "" and this leads it down the signed/unsigned road.

Will check tomorrow what is going on here. Possibly we need to change the test to C++, where compile-time detection of these things is a breeze (because of overloading).

Cheers and thanks,

Gabor

...

-- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs