November 2016 - ghc-tickets

[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 17 Nov '16

17 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 17 Nov '16

17 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 17 Nov '16

17 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 17 Nov '16

17 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

[GHC] #12702: Don't warn about redundant constraints for necessary
by GHC 17 Nov '16

17 Nov '16

#12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached example, GHC warns that the constraint on line 16 of Main.hs is redundant. {{{ • Redundant constraint: e ~ FGCD r s • In the type signature for: foo :: (e ~ FGCD r e', e' ~ (e * (s / r)), e ~ FGCD r s) => Proxy s -> Proxy r -> () }}} However, when I remove that constraint, I get the following error: {{{ • Occurs check: cannot construct the infinite type: t0 ~ Factored.FMul (FGCD r t0) (Factored.FDiv s r) The type variable ‘t0’ is ambiguous • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: forall e e' r s. (e ~ FGCD r e', e' ~ (e * (s / r))) => Proxy s -> Proxy r -> () }}} I'm not entirely sure if the error is correct or not; I can't figure out what it's getting on about. So: if the constraint is required to make `foo` compile, then it is most certainly ''not'' redundant, and there shouldn't be a warning suggesting its removal. If the constraint really isn't required, then the error is a bug. (I apologize for the second bug involving singletons in as many days; I simply don't know an easy way to remove that dependency.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 17 Nov '16

17 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Test Suite | Version: 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: | -------------------------------------+------------------------------------- Changes (by Shayan-Najd): * cc: Shayan-Najd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 17 Nov '16

17 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Test Suite | Version: 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 simonpj): Let me just say: the current status quo of `HsSyn` is not a matter of careful design, and I'm quite open to moving it around. For example, we should fix comment:10 by fixing `HsSyn`! If I don't comment much it's because I'm happy to see progress here, but busy; not because I'm resisting it :-). Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing.
by GHC 16 Nov '16

16 Nov '16

#9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2