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 <ggreif@gmail.com> wrote:
On 2/8/13, Stephen Paul Weber <singpolyma@singpolyma.net> 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