- ghc-tickets - Haskell.org

[GHC] #11532: ghc: panic! occured
by GHC 19 Nov '16

19 Nov '16

#11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- I'd like to try install by following: {{{ $ cabal sandbox init $ cabal install metadata Resolving dependencies... Notice: installing into a sandbox located at /home/cutsea110/devel/haskell/sandbox/.cabal-sandbox Configuring metadata-0.4.2.0... Building metadata-0.4.2.0... : : [1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot ) [1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): LocalReg's live-in to graph cpd3t {_sp8MJ::P64} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: metadata-0.4.2.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- regards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12754: Adding an explicit export list halves compilation time.
by GHC 19 Nov '16

19 Nov '16

#12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- A file only containing a 10000 constructor enumeration type compiles twice as fast with an explicit export list compare to having no export list. {{{ # print "module A where" print "module A (T ( .. ) ) where" print "\n" print "data T = C" for i in range(0,10000): print (" | C" + str(i)) }}} Without an export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m22.872s user 0m19.653s sys 0m0.868s }}} With the export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m11.249s user 0m10.428s sys 0m0.435s }}} The culprit here is `exports_from_avail`, in the case that no export list is provided, the things to export are gathered from the `GlobalRdrEnv`. Each constructor is placed in its own `Avail` which are then combined by `plusAvail` which is implemented using the expensive `unionLists`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12840: GHC-internal triplets passed to sub-project configure scripts
by GHC 19 Nov '16

19 Nov '16

#12840: GHC-internal triplets passed to sub-project configure scripts -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- In some cases GHC normalizes the target triplet passed to configure to a value that is not a valid autoconf target. #12487 mistakenly changed the build to pass these triplets to sub-project configure scripts, such as that for 'base', causing a configure error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12777: reify yields the wrong type in the presence of functional rependencies
by GHC 19 Nov '16

19 Nov '16

#12777: reify yields the wrong type in the presence of functional rependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- {{{reify}}} yields an incomplete type in the following program. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE FunctionalDependencies #-} module B where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH class C a b | a -> b where yo :: a -> IO b instance C Bool Int where yo = undefined t3 :: IO () t3 = do x <- yo True $(do addModFinalizer $ TH.reify 'x >>= runIO . print [| return () |] ) }}} {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627401898 (VarT a_1627404604) Nothing }}} The problem seems to be that finalizers run before functional dependencies are considered. Hacking ghc to run finalizers after {{{simplifyTop}}} produces the expected output instead: {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627404863 (ConT GHC.Types.Int) Nothing }}} Would anyone object to running finalizers after {{{simplifyTop}}}? This implies that finalizers shouldn't add definitions (with {{{addTopDecls}}}) which depend on {{{simplifyTop}}} to be type-checked. Another option is to call {{{simplifyTop}}} before and after running finalizers. But is it safe to do so? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12807: GHC is too verbose by default (source/object paths)
by GHC 18 Nov '16

18 Nov '16

#12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the default verbosity, GHC shows the path of the source file and the path of the object file (or "interpreted" in GHCi) making the lines very long as in the following example: {{{ [133 of 159] Compiling ViperVM.Arch.Linux.Internals.Input ( src/lib/ViperVM/Arch/Linux/Internals/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Input.o ) [134 of 159] Compiling ViperVM.Arch.Linux.Input ( src/lib/ViperVM/Arch/Linux/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Input.o ) [135 of 159] Compiling ViperVM.System.Input ( src/lib/ViperVM/System/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/System/Input.o ) [136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound ( src/lib/ViperVM/Arch/Linux/Internals/Sound.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Sound.o ) [137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics ( src/lib/ViperVM/Arch/Linux/Internals/Graphics.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Graphics.o ) }}} In most cases, I think we don't need these paths. I propose that we keep this output for the verbose mode and that we change the default behaviour to something like: {{{ [135 of 159] Compiling ViperVM.System.Input (.hs -> .o) [136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound (.hs -> .o) -- GHCi [137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics (.hs -> interpreted) }}} It is also particularily nice with BackPack that uses hashes in output paths: we may not want to expose them to users by default. Example: {{{#!patch [1 of 1] Including p[A=r:A] Instantiating p[A=r:A] - [1 of 2] Compiling A[sig] ( p/A.hsig, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/A.o ) - [2 of 2] Compiling P ( p/P.hs, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/P.o ) - [1 of 1] Compiling M ( q/M.hs, bkp26.out/q/M.o ) + [1 of 2] Compiling A[sig] (.hsig -> .o) + [2 of 2] Compiling P (.hs -> .o) + [1 of 1] Compiling M (.hs -> .o) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ()))
by GHC 18 Nov '16

18 Nov '16

#12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds #-} import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu (Const ())) }}} produces {{{ • No instance for (Data (Const () (Mu (Const ())))) arising from a use of ‘k’ • In the expression: (z Mu `k` a1) In an equation for ‘gfoldl’: gfoldl k z (Mu a1) = (z Mu `k` a1) When typechecking the code for ‘gfoldl’ in a derived instance for ‘Data (Mu (Const ()))’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Data (Mu (Const ()))’ }}} while other type constructors work, e.g. {{{#!hs deriving instance Data.Data.Data (Mu []) deriving instance Data.Data.Data (Mu ((,) ())) }}} i am not sure if #10835 is related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks
by GHC 18 Nov '16

18 Nov '16

#8321: improve basic block layout on LLVM backend by predicting stack/heap checks ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently we don't give the LLVM optimizer any information about which branch of an `if` is likely to be taken. As a result, the optimizer is likely to produce a basic block layout which is not optimal. Improving the layout can improve performance through better instruction cache usage and better branch prediction by the hardware. We can control LLVM's idea of what is likely with the `llvm.expect` intrinsic function. Some obvious branches which we can predict accurately are the stack and heap checks that appear near the entry of many functions. Here's a small example of some Cmm code and the output of the LLVM optimizer/compiler. {{{ block_c2Lc_entry() // [R1, R2] { info_tbl: [(c2Lc, label: block_c2Lc_info rep:StackRep [])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c2Lc: Hp = Hp + 24; if (Hp > HpLim) goto c2Lm; else goto c2Ll; c2Lm: HpAlloc = 24; R2 = R2; R1 = R1; call stg_gc_pp(R2, R1) args: 8, res: 8, upd: 24; c2Ll: I64[Hp - 16] = :_con_info; P64[Hp - 8] = R1; P64[Hp] = R2; R1 = Hp - 14; Sp = Sp + 8; call (P64[Sp])(R1) args: 24, res: 0, upd: 24; } }] }}} {{{ 00000000000002b8 <c2Lc_info>: 2b8: 4c 89 e0 mov %r12,%rax 2bb: 4c 8d 60 18 lea 0x18(%rax),%r12 2bf: 4d 3b a5 18 01 00 00 cmp 0x118(%r13),%r12 2c6: 76 10 jbe 2d8 <c2Lc_info+0x20> 2c8: 49 c7 85 48 01 00 00 movq $0x18,0x148(%r13) 2cf: 18 00 00 00 2d3: e9 00 00 00 00 jmpq 2d8 <c2Lc_info+0x20> 2d4: R_X86_64_PC32 stg_gc_pp+0xfffffffffffffffc 2d8: 48 c7 40 08 00 00 00 movq $0x0,0x8(%rax) 2df: 00 2dc: R_X86_64_32S ghczmprim_GHCziTypes_ZC_con_info 2e0: 48 89 58 10 mov %rbx,0x10(%rax) 2e4: 4c 89 70 18 mov %r14,0x18(%rax) 2e8: 48 8b 45 08 mov 0x8(%rbp),%rax 2ec: 48 83 c5 08 add $0x8,%rbp 2f0: 49 8d 5c 24 f2 lea -0xe(%r12),%rbx 2f5: ff e0 jmpq *%rax 2f7: 90 nop }}} It would likely be better to invert the branch at `2c6` to a `ja`, so that the common case is adjacent to the function entry, and when `llvm.expect` is used on the condition in the branch, the LLVM optimizer does produce this alternate layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12849: hsc2hs trouble with floating-point constants in cross-compilation mode
by GHC 18 Nov '16

18 Nov '16

#12849: hsc2hs trouble with floating-point constants in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.4 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: -------------------------------------+------------------------------------- Split off from #7983. GCC 4.6 rejects some uses of floating-point constants in the declaration of a local static array. From ticket:7983#comment:5: > This is caused by a regression in GCC from gcc-4.4 to gcc-4.6: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028 > > {{{ > $ cat Test_hsc_test0.c > void _hsc2hs_test1() > { > static int test_array[(89.) > 0 ? 2 : 1]; > } > > $ /usr/bin/gcc-4.4 -c ./Test_hsc_test0.c > > $ /usr/bin/gcc-4.6 -c ./Test_hsc_test0.c > ./Test_hsc_test0.c: In function ‘_hsc2hs_test1’: > ./Test_hsc_test0.c:3:16: error: storage size of ‘test_array’ isn’t constant > }}} This means that (if your C compiler is affected by this issue) hsc2hs can't handle {{{ (#const 89.) }}} in cross-compilation mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7983: Bug in hsc2hs --cross-safe
by GHC 18 Nov '16

18 Nov '16

#7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Created #12849. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7983#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7983: Bug in hsc2hs --cross-safe
by GHC 18 Nov '16

18 Nov '16

#7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): There seem to be two issues here. 1. The program is accepted by `hsc2hs --cross-safe` even though it's rejected by `hsc2hs --cross-compile`. 2. The program is rejected by `hsc2hs --cross-compile` for reasons that seem to have to do with the use of doubles. The ticket seems to have been intended to be about 1, since it's titled "Bug in `hsc2hs --cross-safe`". In general this has nothing to do with the weirdness of point 2. For example, you could write something clearly non- constant like `(#const getpid())`. hsc2hs will accept this in direct mode, which is okay I think; but it certainly won't work in cross-compiling mode, so `hsc2hs --cross-safe` should reject it too. I think this should be easy to implement: just include the output of `CrossCodegen.outValidityCheck` in the direct code generation path as well, if `--cross-safe` is enabled. I will create a separate ticket for point 2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7983#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0