September 2017 - ghc-tickets

[GHC] #13963: Runtime representation confusingly displayed
by GHC 15 Sep '17

15 Sep '17

#13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- 8.3.20170605: {{{ > :set -XRankNTypes -XTypeInType > import GHC.Exts (TYPE, RuntimeRep(LiftedRep)) > type Pair (a::TYPE rep) (b::TYPE rep') rep'' = forall (r::TYPE rep''). (a -> b -> r) -> r > :kind Pair Pair :: * -> * -> * > :kind Pair Int Pair Int :: * -> * > :kind Pair Int Float Pair Int Float :: * > :kind Pair Int Float LiftedRep Pair Int Float LiftedRep :: * }}} It still behaves oddly with `-fprint-explicit-runtime-reps` enabled {{{ > :set -fprint-explicit-runtime-reps > :kind Pair Pair :: * -> * -> forall (rep'' :: RuntimeRep) -> * > :kind Pair Int Pair Int :: * -> forall (rep'' :: RuntimeRep) -> * > :kind Pair Int Float Pair Int Float :: * > :kind Pair Int Float LiftedRep Pair Int Float LiftedRep :: * }}} I would have also expected to see `Pair`'s kind displayed something like this {{{#!hs forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> * }}} which is how the kind of the corresponding `newtype` gets displayed {{{ > newtype Pair2 (a::TYPE rep) (b::TYPE rep') rep'' = P2 (forall (r::TYPE rep''). (a -> b -> r) -> r) > :kind Pair2 Pair2 :: forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13909: Can't partially apply a data type with a visible quantifier in its kind
by GHC 15 Sep '17

15 Sep '17

#13909: Can't partially apply a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug or an intended design, so I'll ask here. I want this program to typecheck: {{{#!hs {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data Hm (k :: Type) (a :: k) :: Type class HasName (a :: k) where getName :: proxy a -> String instance HasName Hm where getName _ = "Hm" }}} This is rejected, however: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:18: error: • Expecting two more arguments to ‘Hm’ Expected kind ‘k0’, but ‘Hm’ has kind ‘forall k -> k -> *’ • In the first argument of ‘HasName’, namely ‘Hm’ In the instance declaration for ‘HasName Hm’ | 11 | instance HasName Hm where | ^^ }}} The culprit appears to be the fact that `Hm` has kind `forall k -> k -> *`, which uses a visible quantifier. Does this prevent partial applications of `Hm`? Or is this simply a GHC bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12700: Don't warn about redundant constraints for type equalities
by GHC 15 Sep '17

15 Sep '17

#12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `-Wall`, the following code {{{ {-# LANGUAGE TypeFamilies #-} type family Foo x where Foo Double = Int foo :: (RealFrac a, Integral b, b ~ Foo a) => a -> b foo = round }}} produces the warning {{{ • Redundant constraint: b ~ Foo a • In the type signature for: foo :: (RealFrac a, Integral b, b ~ Foo a) => a -> b }}} Technically, I suppose this is correct in the sense that if we remove the constraint `b ~ Foo a`, `foo` still compiles. However, the ''meaning'' changes without the type equality, because the function I wrote is equivalent to `foo :: (RealFrac a, Integral (Foo a)) => a -> Foo a` (which requires `-XFlexibleContexts`), while the function it suggests is the much more general `foo :: (RealFrac a, Integral b) => a -> b`. Since this is the case, I think the warning is invalid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 15 Sep '17

15 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It's always possible that something is broken :) What does the Cmm look like? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 15 Sep '17

15 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): `-fllvm` with LLVM5 and GHC at `8a1de424`, generates some rather interesting IR with -O2: https://ghc.haskell.org/trac/ghc/attachment/ticket/6084/T6084.ll specifically {{{ ... %ln4QS = bitcast void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)* %ln4QT = load i64*, i64** %Sp_Var %ln4QU = load i64, i64* %R1_Var %ln4QV = load i64, i64* %R2_Var %ln4QW = load float, float* %F1_Var %ln4QX = load double, double* %D2_Var tail call ghccc void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double) %ln4QS( i64* %Base_Arg, i64* %ln4QT, i64* %Hp_Arg, i64 %ln4QU, i64 %ln4QV, i64 undef, i64 undef, i64 undef, i64 undef, i64 %SpLim_Arg, float %ln4QW, double %ln4QX ) nounwind ret void } @Main_p_info = alias i8, bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i8*) define ghccc void @Main_p_info$def(i64* noalias nocapture %Base_Arg, i64* noalias nocapture %Sp_Arg, i64* noalias nocapture %Hp_Arg, i64 %R1_Arg, i64 %R2_Arg, i64 %R3_Arg, i64 %R4_Arg, i64 %R5_Arg, i64 %R6_Arg, i64 %SpLim_Arg) align 8 nounwind prefix <{i64, i64, i64, i64, i64, i64}><{i64 add (i64 sub (i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_slow$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 451, i64 add (i64 sub (i64 ptrtoint (%S4QA_srt_struct* @S4QA_srt$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 12884901888, i64 0, i64 4294967310}> { ... }}} we bitcast `@Main_p_info$def` from `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)` to `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)`. (E.g. we add a `float` and a `double`) to the signature. And then we call the newly bitcasted function with an additional float and double. However `Main_p_info$def` doesn't take those two last arguments, and never does anything with them. At the point where we create `Main_p_info$def` (the `CmmProc`) the `live` value hence does not include registers `F1` and `D1`. Yet at the call site we do expect to pass them. The LLVM backend, simply ignores this, as it always casts functions to the expected type. However a more rigorous backend that tries to unify functions with their callsite signatures falls over at this point. Is it possible that some liveness logic is broken in Cmm here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 15 Sep '17

15 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+--------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | -------------------------------------+--------------------------------- Changes (by angerman): * Attachment "T6084.ll" added. T6084.ll -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

14 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

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 14 Sep '17

14 Sep '17

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): Note that Phab:D3967 may be relevant to some of the issues reported above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11819: Full validation issues for 8.0.1
by GHC 14 Sep '17

14 Sep '17

#11819: Full validation issues for 8.0.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- `./validate --slow` gave rise to some failures. Re-running them resulted in, {{{ make fulltest TEST="overloadedrecfldsrun04 overloadedlabelsrun04 SplicesUsed scc003 T5654b-O1 T5654b-O0 T9646 T5550 T2120 Rules1 T7837 T10697_decided_3 qq007 qq008 qq009 T9078 overflow3 overflow2 overflow1 T10728 T7919 forkprocess01 TH_spliceViewPat T8089 haddock.Cabal" ... Unexpected results from: TEST="overloadedrecfldsrun04 overloadedlabelsrun04 SplicesUsed scc003 T5654b-O1 T5654b-O0 T9646 T5550 T2120 Rules1 T7837 T10697_decided_3 qq007 qq008 qq009 T9078 overflow3 overflow2 overflow1 T10728 T7919 TH_spliceViewPat T8089 haddock.Cabal" OVERALL SUMMARY for test run started at Sun Apr 10 19:55:59 2016 EDT 0:02:54 spent to go through 25 total tests, which gave rise to 186 test cases, of which 40 were skipped 0 had missing libraries 110 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 35 unexpected failures 1 unexpected stat failures Unexpected failures: ../../libraries/array/tests T2120 [bad stdout] (profasm,profthreaded) ../../libraries/base/tests T8089 [bad profile] (profasm,profthreaded) indexed-types/should_compile Rules1 [exit code non-0] (profasm) indexed-types/should_compile T7837 [stderr mismatch] (profasm) overloadedrecflds/should_run overloadedlabelsrun04 [exit code non-0] (profasm,profthreaded) overloadedrecflds/should_run overloadedrecfldsrun04 [exit code non-0] (profasm,profthreaded) partial-sigs/should_compile SplicesUsed [exit code non-0] (profasm) profiling/should_run T5654b-O0 [exit code non-0] (prof) profiling/should_run T5654b-O1 [exit code non-0] (profasm) profiling/should_run scc003 [bad profile] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) quasiquotation/qq009 qq009 [exit code non-0] (profasm) quotes/TH_spliceViewPat TH_spliceViewPat [exit code non-0] (profasm,profthreaded) rts T10728 [bad stdout] (profasm,threaded2,profthreaded) rts T10728 [bad stdout or stderr] (ghci) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts overflow1 [bad profile] (profasm,profthreaded) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/T9646 T9646 [bad stdout or stderr] (ghci) simplCore/should_compile T5550 [exit code non-0] (profasm) th T10697_decided_3 [bad stdout or stderr] (ghci) Unexpected stat failures: perf/haddock haddock.Cabal [stat not good enough] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14234: Enable -Wconversion for GHC's C code
by GHC 14 Sep '17

14 Sep '17

#14234: Enable -Wconversion for GHC's C code -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Because apparently none of `-Wall`, `-Wextra` or `-pedantic` of GCC imply `-Wconversion` or its subset `-Wsign-conversion`: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625 That means currently you can call a function taking an `unsigned int` with a `signed int` without getting any warning. That is very bad, because of course negative numbers will overflow. Having `-Wconversion` would have caught overflow errors such as this one: https://phabricator.haskell.org/D3955#110993 We should probably have it for the C code. Turning it on everywhere will be quite some work though because it creates lots of complaints such as `long long int` not being the same as `long int` (which is technically correct but in practice they are typically the same). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0