I have a patch waiting to be pushed that should fix this, noticed it myself a few days back. For me though the problem was only occurring on Windows and Linux was working fine as of yesterday. The patch is pretty simple but I need to do a little more testing of it before I push, especially since its failing on Linux now.
For interest, the problem seems to have occurred due to changes in GHC's inliner or some other optimisation pass. I encode all floats into a hexadecimal form, which LLVM expects to be the same for both floats and doubles. The only difference is while floats are encoded in a kind of double hexadecimal form they need to be of a precision that fits into a float. I was doing this before basically be having something like ((realToFrac :: Double -> Float) . (realToFrac :: Float -> Double)). Recently GHC seems to have learned to optimise this by removing that code completely. (Before if I told GHC not to inline some stuff this stopped it doing that, but not anymore it seems). On 23 September 2010 18:12, Simon Marlow <[email protected]> wrote: > Hi David, > > We have some LLVM failures on the 32-bit Linux nightly build. > > On 23/09/2010 03:42, GHC Build Reports wrote: > >> Unexpected failures: >> arith005(optllvm) >> barton-mangler-bug(optllvm) >> cgrun026(optllvm) >> cgrun034(optllvm) >> cgrun044(optllvm) >> drvrun017(optllvm) >> expfloat(optllvm) >> fun_insts(optllvm) >> num008(optllvm) >> num009(optllvm) > > The error messages are all the same. Here's an example: > > =====> num008(optllvm) 922 of 2592 [0, 6, 0] > cd ./lib/Numeric && > '/playpen/simonmar/nightly/HEAD/i386-unknown-linux/inplace/bin/ghc-stage2' > -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -rtsopts > -dno-debug-output -o num008 num008.hs -O -fllvm >num008.comp.stderr 2>&1 > Compile failed (status 256) errors were: > [1 of 1] Compiling Main ( num008.hs, num008.o ) > opt: /playpen/tmp/ghc28376_0/ghc28376_0.ll:43:139: error: floating point > constant invalid for type > @Main_main11_closure = global %Main_main11_closure_struct <{i32 ptrtoint > ([0 x i32]* @ghczmprim_GHCziTypes_Fzh_static_info to i32),float > 0x01B385232A2E2941}> > > Any ideas? > > Cheers, > Simon > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
