May 2016 - ghc-tickets

[GHC] #11342: Character kind
by GHC 28 Sep '17

28 Sep '17

#11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We know and love the Symbol kind, but as far as I know it's not possible to analyse a Symbol type, as we would a String term. It would be nice to have a Character kind and some related type families: {{{#!hs data Character -- Pattern match a Symbol. 'Nothing when empty, 'Just '(head, tail) -- otherwise. type family UnconsSymbol (s :: Symbol) :: Maybe (Character, Symbol) -- Put a Character at the head of a Symbol. type family ConsSymbol (c :: Character) (s :: Symbol) :: Symbol -- Work with Characters. Ideally we'd have counterparts for every -- function on Data.Char. type family ToUpper (c :: Character) :: Character type family IsAlpha (c :: Character) :: Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9898: Couldn't match type `(Char, ())' with `()'
by GHC 27 Sep '17

27 Sep '17

#9898: Couldn't match type `(Char, ())' with `()' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'test3' is expected to type check given that 'test1' and 'test2' type check. 'test4' is not expected to type check. {{{ ghc_bug2.hs:24:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, Filter (Equal Int) ()) Actual type: () In the expression: () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) In an equation for `test2': test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) ghc_bug2.hs:28:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, ()) Actual type: () In the expression: () In an equation for `test3': test3 = () }}} {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances, DataKinds #-} module Main where type family Filter f xs where Filter f (x, xs) = ApplyFilter (f x) (x, Filter f xs) Filter f () = () -- type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs -- type family Equal x y where Equal x x = True Equal x y = False -- -- Type checks test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) test1 = () -- Couldn't match type `(Char, ())' with `()' test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) -- Couldn't match type `(Char, ())' with `()' test3 :: Filter (Equal Int) (Char, ()) test3 = () -- Type checks, should not test4 :: Filter (Equal Int) (Char, ()) test4 = ('x', ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12110: Windows exception handler change causes segfault with API Monitor
by GHC 27 Sep '17

27 Sep '17

#12110: Windows exception handler change causes segfault with API Monitor ----------------------------------------+---------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- [http://www.rohitab.com/apimonitor API Monitor] is a debugging tool that intercepts and logs calls to DLLs. It was extremely helpful with debugging #12010 and is broken in recent GHCs. Attaching it to a GHC compiled executable causes the message `Segmentation fault/access violation in generated code` to be printed. Launching one from inside API Monitor doesn't work either, though I can't read the console output before the window closes. Bisect shows the offending commit is 5200bdeb26 - "Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64". I know this is somewhat outside of "standard usage", but there are very few useful debugging tools for stuff like this and I'd really like to not lose this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11198: TypeInType error message regressions
by GHC 27 Sep '17

27 Sep '17

#11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `TypeInType` causes error messages around certain kind errors to degrade. Here is the case: {{{ [W] (alpha :: k) ~ (Int :: *) }}} where `alpha` is a unification variable, `k` is a skolem, and there is no witness that `k ~ *`. The solver will simplify to {{{ [W] kco :: k ~ * [W] (alpha :: k) ~ (Int |> sym kco) }}} and then the latter, now homogeneous equality is solved by unification {{{ alpha := Int |> sym kco }}} This is all sound. But when reporting a kind error around `k` not equalling `*`, GHC likes to report the type error that the kind error came from. But, after zonking, the type error looks like `Int ~ Int`, when we drop coercions (as we tend to do in error messages). That's unfortunate. It affects test cases * T9196 * T8262 * T8603 * tcfail122 Simon has proposed a rule that should avoid this: never, ever use a wanted as a kind cast. That might work, but an attempt at implementing caused a loop when kind families were involved. I will keep pushing on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8919: Why is xhtml library installed but not exported to users?
by GHC 20 Sep '17

20 Sep '17

#8919: Why is xhtml library installed but not exported to users? ------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions
by GHC 20 Sep '17

20 Sep '17

#9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. This rewrite can be done incrementally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #9157: cmm common block not eliminated
by GHC 20 Sep '17

20 Sep '17

#9157: cmm common block not eliminated ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in. In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code. BTW, this is how they match in France. {{{ #!ocaml type alt = A of int | B of int | C of int | D of int let g x = match x with A v | B v | C v | D v -> v }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs
by GHC 18 Sep '17

18 Sep '17

#9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10601: GHC should be distributed with debug symbols
by GHC 16 Sep '17

16 Sep '17

#10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that we have the capability of producing code with DWARF symbols, we should distribute GHC with them, or at least give the option. The DWARF symbols in these case would be both for the C RTS and for the base Haskell libraries shipped with GHC. Building GHC with said symbols amounts to adding {{{ GhcRtsHcOpts += -g GhcLibHcOpts += -g }}} to `mk/build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11649: LLVM code generator produces mal-formed LLVM blocks
by GHC 15 Sep '17

15 Sep '17

#11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to compile with, {{{ Entry block to function must not have predecessors! label %cjGw /home/ben/ghc/roots/llvm-3.7/bin/opt: libraries/base/GHC/Generics.ll: error: input module is broken! }}} The problematic block in question appears to be, {{{ define internal ghccc void @rhSw_info$def(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noal ias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) align 4 nounwind prefix <{ i32, i32, i32}><{i32 65541, i32 0, i32 15}> { clpH: br label %clpH } }}} Which arose from this Cmm, {{{ ==================== Post control-flow optimisations ==================== 2016-02-26 10:39:28.656744 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [] { info_tbl: [(clpH, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset clpH: goto clpH; // CmmBranch } }] }}} Which arose from this input Cmm, {{{ ==================== Cmm produced by new codegen ==================== 2016-02-26 10:39:28.611641 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [R2] { info_tbl: [(clpD, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 4 updfr_space: Just 4 } {offset clpD: _shWa::P32 = R2; // CmmAssign goto clpz; // CmmBranch clpz: if ((old + 0) - <highSp> < SpLim) goto clpE; else goto clpF; // CmmCondBranch clpE: R2 = _shWa::P32; // CmmAssign R1 = lvl_rhSw_closure; // CmmAssign call (stg_gc_fun)(R2, R1) args: 4, res: 0, upd: 4; // CmmCall clpF: goto clpy; // CmmBranch clpy: goto shWb; // CmmBranch shWb: goto clpH; // CmmBranch clpH: goto shWb; // CmmBranch } }] }}} Which arose from this STG, {{{#!hs lvl_rhSw :: forall a_a99i. GHC.Generics.U1 a_a99i -> GHC.Generics.U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,U>x, Unf=OtherCon []] = sat-only \r [eta_shWa] let-no-escape { some_v_shWb [Occ=LoopBreaker] :: GHC.Generics.U1 [a12_a99i] [LclId, Str=DmdType b] = NO_CCS[] \u [] some_v_shWb; } in some_v_shWb; }}} Which arose from this Core, {{{#!hs lvl_rhSw :: forall a_a99i. U1 a_a99i -> U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,U>x] lvl_rhSw = \ (@ a12_a99i) _ [Occ=Dead] -> letrec { some_v_a99l [Occ=LoopBreaker] :: U1 [a12_a99i] [LclId, Str=DmdType b] some_v_a99l = some_v_a99l; } in some_v_a99l }}} Which is apparently the body of the `some` implementation in the `Alternative` instance for `GHC.Generics.U1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17