- ghc-tickets - Haskell.org

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 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

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

15 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

[GHC] #13407: Fix printing of higher-rank kinds
by GHC 14 Sep '17

14 Sep '17

#13407: Fix printing of higher-rank kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Witness this GHCi session: {{{ rae:09:18:37 ~/ghc/ghc> ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType -XRankNTypes Prelude> import Data.Kind Prelude Data.Kind> data Foo :: (* -> *) -> (forall k. k -> *) Prelude Data.Kind> :info Foo type role Foo phantom nominal phantom data Foo (a :: * -> *) k (c :: k) -- Defined at <interactive>:3:1 }}} The output from `:info` is terrible, treating `k` as a visible parameter when it isn't. This is spun off from #13399 but is not tightly coupled to that ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks
by GHC 14 Sep '17

14 Sep '17

#10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: | Owner: TobyGoodwin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown performance | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: see ticket | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been studying a compiler performance problem in ghc-7.8.4 which is not seen in ghc-7.6.3. Profiling shows the compiler spends 74.3% of its time in `elimCommonBlocks` (in `compiler/cmm/CmmCommonBlockElim.hs`). I came across the problem in real code, and rwbarton on #ghc was able to turn it into a sensible test case, which can be found at http://static.tobold.org/ghc-prof/code/ It's not really a regression, since `elimCommonBlocks` is not enabled by default in 7.6. It can be turned on with `-fnew-codegen`, and that demonstrates a similar slowdown. However 7.8 is worse than 7.6, and 7.10 slightly worse still, for reasons that I haven't explored. Compile times for `RegBig.hs` are: {{{ 7.6.3 -O2 17s 7.6.3 -O2 -fnew-codegen 177s 7.8.4 -O2 230s 7.10.1 -O2 241s }}} The problem obviously stems from the applicative expression with lots of branches `Foo <$> a <*> b <*> c <*> ...` It seems that some level of inlining occurs which means that each extra term in this expression doubles the size of the code. Incidentally, this blowup only occurs when both `RegBig.hs` ''and'' `Form.hs` are compiled with `-O2`. I haven't looked to see why the blowup occurs; although I do see that a similar blowup happens with 7.6. {{{ ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 16,525, types: 31,503, coercions: 73} Result size of Simplifier iteration=2 = {terms: 29,070, types: 45,079, coercions: 73} Result size of Simplifier iteration=3 = {terms: 50,139, types: 62,057, coercions: 73} Result size of Simplifier iteration=4 = {terms: 84,172, types: 83,805, coercions: 73} Result size of Simplifier = {terms: 84,172, types: 83,805, coercions: 73} ... }}} I've looked in some detail at what happens next, tinkering with `elimCommonBlocks` to try to understand why it runs so slowly in this case. There are two major problems. First, `elimCommonBlocks` is worse than O(n^2^), and the inlining blowup mentioned above results in a very large input: 51695 blocks in this example. (Across the project of 50 files or so where this problem originated, I see the input to `elimCommonBlocks` is normally a few hundred blocks at most.) Secondly, there is an effort made in `elimCommonBlocks` to avoid comparing whole blocks all the time, by computing a hash value of some of the block. This fails to produce sufficient unique hash values for this case. The hash must obviously omit the unique block label, and in practice all labels, and various other things, are omitted. In this case, presumably because the code is blown up from the tiny input, many many blocks are similar, and the differences are elided by the hash function. For example, 8177 blocks share the hash value 1094. These 8177 similar blocks all end up in a normal list, which is searched with Data.List.find and the full-block comparison function! Eventually this process concludes that the vast majority are in fact different: for all its hard work, `elimCommonBlocks` only finds about a dozen common blocks in total. Two blocks which both hash to 1094 are these: {{{ cCHc: _se0q::P64 = R1; _c1grM::P64 = _se0q::P64 & 7; if (_c1grM::P64 >= 2) goto c1grR; else goto c1grS; cWK7: _sig3::P64 = R1; _c1iXk::P64 = _sig3::P64 & 7; if (_c1iXk::P64 >= 2) goto c1iXp; else goto c1iXq; }}} I suggest the following steps need to be taken. == 1. Mitigation == Since this is a real problem in the 7.8 and 7.10 series, it needs a simple but effective mitigation. I suggest a test that the input to `elimCommonBlocks` is not "too big", where 1000 seems a reasonable cutoff. Another simple mitigation would be to disable common block elimination altogether (after all, `-O2` is usually understood to mean "make my code go faster even if it gets bigger"). I've tried both these possibilities with 7.8.4. The trivial patches are http://static.tobold.org/ghc-prof/0001-cbe-cutoff.patch and http://static.tobold.org/ghc-prof/0001-no-cbe.patch Compilation times for the test case `RegBig.hs` are as follows, and there is no difference in size in the `.o` file. {{{ 7.8.4 -O2 230s cbe only if input < 1000 blocks 88s no common block elimination 86s }}} == 2. Investigation == I focused on `elimCommonBlocks` thinking that the inline blowup seen earlier in the compilation is reasonable. On reflection, this is probably not so, and I think someone better acquainted with ghc internals should investigate this. == 3. Optimization == `-- TODO: Use optimization fuel` it says in `CmmCommonBlockElim.hs` Since `elimCommonBlocks` is essentially doing a `nub`, it will never perform better than O(n^2^). In fact, it's currently much worse than that as the comparison function changes as duplicate blocks are found, which in turn may create new duplicates, so we have to iterate the nub function till no more dups are found. I did experiment with improving the hash function. It's possible to include target labels, at the expense of needing to recompute block hash values on each iteration. (And currently some ''highly'' ugly code to convert labels to integers.) This considerably reduces the length of some of the hash bucket lists, and so offers a significant speedup: {{{ ghc-7.8.4 -O2 230s "hack" 170s }}} Patch for this is http://static.tobold.org/ghc-prof/0001-cbe-hacks.patch This looks like a promising approach. Including target labels doesn't eliminate all the large hash buckets, so there is scope for further improvements along these lines. I don't see any reason why the hash function should not be as discerning as the equality function, with just occasional accidental clashes. I've also pondered whether more radical rewriting of `elimCommonBlocks` might pay dividends. It's a commonplace that, if you don't need to preserve order, `map head . group . sort` is a faster `nub`. Is the order of blocks significant? I'm not sure - they all seem to end with either `goto` or `call`. I'd ''assume'' that `call` then falls through to the next block but I'm not sure. Anyway, presumably we could `zip [0..]` first, and sort again afterwards, and that should still be asymptotically faster than `nub`. Of course, this presupposes that blocks could be (sensibly? efficiently?) made an instance of `Ord`. (If they were, hash buckets could be stored in an O(1) data structure and binary search employed.) I may be able to find time to pursue some of these avenues, but as a very novice ghc hacker, I'd need some strategic direction here. Any thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #14175: Panic repSplitTyConApp_maybe
by GHC 14 Sep '17

14 Sep '17

#14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This definition panics! {{{#!hs {-# LANGUAGE TypeFamilies, TypeInType #-} module Whoops where import Data.Kind type family PComp (k :: j -> Type) (x :: k) :: () }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170828 for x86_64-unknown-linux): repSplitTyConApp_maybe j_aon[sk:1] * * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1123:5 in ghc:Type }}} If I make it a type synonym instead, I get a proper error as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11