November 2014 - ghc-tickets

[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] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot
by GHC 24 Dec '15

24 Dec '15

#9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that {{{ Myfile.hs:1:1: cannot find normal object file 'Othe.dyn_o` while linking an interpreted expression }}} So `Other` was wrongly made into `Othe`, dropping the last character. If I don't pass `-osuf .something`, or have it not have a dot, everything's fine. The trouble is that `-osuf .something` worked fine in GHC <= 7.6. So I believe this is a regression, or at least a very bad error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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

[GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by GHC 16 Dec '15

16 Dec '15

#9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 32

[GHC] #9306: Crash when shifting Integers too much
by GHC 16 Dec '15

16 Dec '15

#9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer@lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8347: Add a Strict LANGUAGE pragma
by GHC 16 Dec '15

16 Dec '15

#8347: Add a Strict LANGUAGE pragma ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8424: quasi-quotes have carriage returns on Windows
by GHC 16 Dec '15

16 Dec '15

#8424: quasi-quotes have carriage returns on Windows ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A Windows user rerported using Data.Text.IO.writeFile to write out quasi- quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? I asked this question on ghc-users and there was no response. I am willing to make this fix if it is deemed appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6