October 2014 - ghc-tickets

[GHC] #9590: AMP breaks `haskell2010` package
by GHC 02 Jan '16

02 Jan '16

#9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Operating System: Keywords: AMP | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: ``` $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. λ:2> data Identity a = Identity a data Identity a = Identity a λ:3> instance Monad Identity <interactive>:3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ‘Monad Identity’ λ:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’ instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’ instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’ λ:5> ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__
by GHC 31 Dec '15

31 Dec '15

#9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Debian packaging added a few hacks to create a CPP macro that can be used to distinguish compilers with Template Haskell support from those that don’t have that support. We need this to compiler some code on non- TH architectures. It works, but we found that we cannot upstream such patches, which is a shame. I propose that among the GHC-defined macros listed at https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, which is available if the compiler supports splices, or ``__GLASGOW_HASKELL_TH__=NO` if not. (I propose a two-valued comparison so that library authors can decide themselves what the default should be if this symbol is not defined, some might want to use TH on older compilers, some not.) I hope this can be part of 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts
by GHC 31 Dec '15

31 Dec '15

#9237: GHC not recognizing "-llibrary" form in implicit linker scripts ----------------------------------+--------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2. I have installed llvm-general-3.4.2.2 and llvm-general-pure-3.4.2.2 from this branch: https://github.com/tvh/llvm- general/tree/curatedTargetMachine, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building: {{{ Building accelerate-llvm-0.15.0.0... Preprocessing library accelerate-llvm-0.15.0.0... [ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package mwc-random-0.13.1.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package setenv-0.1.1.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package llvm-general-pure-3.4.2.2 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package llvm-general-3.4.2.2 ... <command line>: can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) }}} After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works. This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken
by GHC 29 Dec '15

29 Dec '15

#9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ rwbarton@morphism:~/ghc$ ghc --print-gcc-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Gcc Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rwbarton@morphism:~/ghc$ ghc --print-ld-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Ld Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In 2d2650bf65da3aede4e1c1ca4da623092b869dbe and subsequent commits (between 7.6 and 7.8) these settings fields became "C compiler link flags" and "ld flags". (I think, more or less.) The real problem is that Cabal still looks for the settings fields "Gcc Linker flags" and "Ld Linker flags". I guess this should be updated on the Cabal side though. (They are empty on at least Linux x86_64, which I guess is why nobody noticed before.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI
by GHC 26 Dec '15

26 Dec '15

#9414: GHC 7.8.3 compilation fails on Raspberry PI ----------------------------+--------------------------------------- Reporter: ipuustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------- Tried to compile GHC 7.8.3 from the source package on Raspbian (a Debian- based Raspberry PI distribution). The installed GHC version is 7.4.1. All build dependencies for 7.4.1 were installed ('apt-get build-dep ghc'). {{{ "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll- split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist- install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll- split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user- package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist- install/build -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/filepath/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/rts/dist/build' -optl-lgmp -optl-lm -optl-lrt -optl-ldl -fPIC -dynamic -H32m -O -hide-all- packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist- install/build -Iutils/dll-split/dist-install/build/autogen -optP- include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -fno-use- rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../base-4.7.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer- gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split /dist-install/build/Main.dyn_o "cp" -p utils/dll-split/dist-install/build/tmp/dll-split inplace/lib/bin /dll-split "rm" -f inplace/bin /dll-split echo '#!/bin/bash' >> inplace/bin/dll-split echo 'executablename="/home/pi/ghc/ghc-7.8.3/inplace/lib/bin/dll-split"' >> inplace/bin/dll-split echo 'datadir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'bindir="/home/pi/ghc/ghc-7.8.3/inplace/bin"' >> inplace/bin/dll-split echo 'topdir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'pgmgcc="/usr/bin/gcc"' >> inplace/bin/dll-split echo 'export LD_LIBRARY_PATH="/home/pi/ghc/ghc-7.8.3/libraries/filepath /dist-install/build:/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build:/home/pi/ghc/ghc-7.8.3/rts/dist/build:$LD_LIBRARY_PATH"' >> inplace/bin/dll-split echo 'exec "$executablename" ${1+"$@"}' >> inplace/bin /dll-split chmod +x inplace/bin /dll-split inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Keskeytetty make: *** [all] Virhe 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9176: GHC not generating dyn_hi files
by GHC 25 Dec '15

25 Dec '15

#9176: GHC not generating dyn_hi files ----------------------------------+---------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: dynamic | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9739: GHC 7.8 chokes on recursive classes
by GHC 23 Dec '15

23 Dec '15

#9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Type checking this makes GHC 7.8.3 loop: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Foo where class Class3 a => Class1 a where class Class2 t a where class2 :: (Class3 t) => a -> m class (Class1 t, Class2 t t) => Class3 t where }}} Does not happen in 7.6.3. I think it's something to do with the `Class3` constraint appearing in `class2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9394: Show data/type family instances with ghci's :info command
by GHC 18 Dec '15

18 Dec '15

#9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance: {{{#!hs *Application> :info Route App class Eq (Route a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where data family Route a1 ... -- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class' instance Eq (Route App) -- Defined at Foundation.hs:48:1 instance Read (Route App) -- Defined at Foundation.hs:48:1 ................. }}} It just shows info about `Route`, then info about `App` separately. When I try this: {{{#!hs *Application> :info (Route App) <interactive>:1:2: parse error on input `Route' }}} I am getting parse error. I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9276: audit ghc floating point support for IEEE (non)compliance
by GHC 16 Dec '15

16 Dec '15

#9276: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10