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