January 2015 - ghc-tickets

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9421: magic number mismatch when installing 32bit on 64bit machine
by GHC 18 Sep '16

18 Sep '16

#9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Installing Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is basically the same problem as reported here: https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs I've downloaded http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- deb7.tar.xz configured, and make install says: {{{ Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn' Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9089: Local .ghci_history
by GHC 10 Sep '16

10 Sep '16

#9089: Local .ghci_history ------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Hello, It would be nice to allow a local .ghci_history to be used (when available) instead of the global .ghc/ghci_history. This would be similar in behaviour to the .ghci rules: http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/ghci-dot-files.html And I believe this should not be too complicated to do (I can even try it myself, if there is interest). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9880: ghc crashes on th splices in instance context
by GHC 07 Sep '16

07 Sep '16

#9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | 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: -------------------------------------+------------------------------------- Given Class.hs: {{{#!hs module Class where class Foo a where bar :: a -> Int }}} TH.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Class import Language.Haskell.TH mkFun :: Q [Dec] mkFun = return [FunD 'bar [Clause [WildP] (NormalB (LitE (IntegerL 0))) []]] }}} and Instance.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Instance where import TH import Class instance Foo Bool where $(mkFun) }}} compiling the project crashes ghc with {{{ #ghc --make Instance.hs [2 of 3] Compiling TH ( TH.hs, TH.o ) [3 of 3] Compiling Instance ( Instance.hs, Instance.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]mkFun{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9498: GHC links against unversioned .so files
by GHC 16 Aug '16

16 Aug '16

#9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9517: hp2ps generates invalid postscript file
by GHC 07 Aug '16

07 Aug '16

#9517: hp2ps generates invalid postscript file -----------------------------+---------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+---------------------------------- Some of the outputs have a name such as foo(...). However, the postscript generation does not add an extra closing parenthesis after the foo(...). Example from attachment on line 410. ((447)modifyEdge.newEdges.(...) show This should presumably be: ((447)modifyEdge.newEdges.$...$) show Output from ps2pdf: Error: /syntaxerror in -file- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1163/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 40721 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code
by GHC 06 Aug '16

06 Aug '16

#9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In an attempt to close #4210 the LLVM code generator's mangler was modified in ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables. Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues. This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining
by GHC 04 Aug '16

04 Aug '16

#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining ------------------------------------+------------------------------------- Reporter: jberryman | 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: | ------------------------------------+------------------------------------- I just remembered an old idea I put to the GHC user's list [http://www .mail-archive.com/glasgow-haskell-users(a)haskell.org/msg22119.html here], and thought I should present it here. As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like: {{{ {-# INLINE foo #-} foo :: a -> b -> c foo a = \b -> ... }}} It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this: {{{ foo :: a -> {-# INLINE #-} b -> c foo a b = ... -- or: foo = ... }}} ...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta- conversion was required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE
by GHC 04 Aug '16

04 Aug '16

#8589: Bad choice of loop breaker with INLINABLE/INLINE ------------------------------+-------------------------------------------- Reporter: | Owner: NickSmallbone | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Take the following program, which defines a pair of lists recursively: {{{ module Test(xs, ys) where pair :: ([Bool], [Bool]) pair = (False:xs, True:ys) where (xs, ys) = pair (xs, ys) = pair }}} GHC is clever enough to disentangle {{{xs}}} from {{{ys}}} and with {{{-ddump-simpl -O}}} I get: {{{ Rec { xs [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] xs = : False xs end Rec } Rec { ys [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] ys = : True ys end Rec } }}} However, if I mark {{{pair}}} as {{{INLINABLE}}} or {{{INLINE}}} (it doesn't matter which), I get much worse code where {{{xs}}} and {{{ys}}} go through {{{pair}}}: {{{ Rec { pair [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: ([Bool], [Bool]) [GblId, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 50 30 Tmpl= (: False (case pair of _ { (xs1_Xf6 [Occ=Once], _) -> xs1_Xf6 }), : True (case pair of _ { (_, ys1_Xf6 [Occ=Once]) -> ys1_Xf6 }))}] pair = (a1_rgo, a_rgn) ys_ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] ys_ys = case pair of _ { (xs1_XeW, ys1_Xf7) -> ys1_Xf7 } a_rgn :: [Bool] [GblId, Str=DmdType] a_rgn = : True ys_ys xs_xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] xs_xs = case pair of _ { (xs1_XeW, ys1_XeS) -> xs1_XeW } a1_rgo :: [Bool] [GblId, Str=DmdType] a1_rgo = : False xs_xs end Rec } ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] ys = ys_ys xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] xs = xs_xs }}} It seems that GHC chooses {{{pair}}} as the loop breaker, which stops the simplifier in its tracks. It might seem a bit silly to mark {{{pair}}} as {{{INLINE}}}, since it's not mutually recursive. The function I really had was polymorphic with a typeclass constraint, and I wrote {{{INLINABLE}}} to get it specialised at its call site. (Also, {{{pair}}} is mutually recursive in the Core, so you would expect GHC to avoid using it as a loop breaker if I mark it {{{INLINE}}}.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8