- ghc-tickets - Haskell.org

[GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter
by GHC 26 Nov '15

26 Nov '15

#10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A friend of mine accidentally lost a bunch of uncomited code because he passed the name of his source file to ghci's ctags command {{{ :ctags hisstuff.hs }}} He tought that the ctags parameter was the name of the file to create the ctags from. Instead, that parameter is actually for the name of the file to write the tags to. His Haskell source file was instantly overwritten by the tag info. The source of this confusion is that the the documentation from the `:help` command just says it takes a "file" parameter, without explicitly mentioning that its the name of the *output* file. {{{ :ctags[!] [<file>] create tags file for Vi (default: "tags") (!: use regex instead of line number) :etags [<file>] create tags file for Emacs (default: "TAGS") }}} I think it would be safer to use a more precise name here instead of `<file>`. Something like `<output>` or `<outputFile>`. It might also be a good idea to forbid the ctags and etags commands from overwriting existing "hs" and "lhs" source files. If a user types `:ctags something.hs` then its almost certainly a mistake with potentially destructive consequences. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10952: Use IPids instead of package keys in HPC tix files
by GHC 26 Nov '15

26 Nov '15

#10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- With GHC 7.10.2, HPC module names are stored in the format "package_key/Module.Name", rather than "package_id/Module.Name". In stack, we restrict the coverage results to just the library modules by using the "--include" flag. For GHC 7.10, this means I need to ask ghc- pkg what the package key is in order to figure out what to pass in for "-- include" (see this issue: https://github.com/commercialhaskell/stack/issues/785) I thought this was done correctly, but now I'm seeing some cases where coverage is reporting (0/0) due to the wrong package key being passed in... I think I need to run the ghc-pkg query with the package's ipid rather than name.. So, I need to have the correct ipid somewhere, in order to run ghc-pkg describe, parse its results to find out what the package key is, and then finally pass this in as a CLI argument. The hpc program's CLI is already woefully error-prone (see https://ghc.haskell.org/trac/ghc/ticket/10951) but this makes it plain hellish. Is there a better way to do what I need to do here? I think the right approach to resolving this is to put the full ipid in the HPC files. Then, the hpc program should be modified to allow "-- include" argument to take multiple package identification formats - ipid, package identifier, or package name. If the full package name was included, I could at least do some custom tix file munging based on just the package name. As things stand, the only way I can meaningfully operate on tix files is if I have the correct package key. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10952> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 26 Nov '15

26 Nov '15

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: siddhanathan Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | 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 siddhanathan): * owner: => siddhanathan -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #367: Infinite loops can hang Concurrent Haskell
by GHC 26 Nov '15

26 Nov '15

#367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler | allocation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"9aa94586fde73e818e32e5cc0e6420f6ed36a80b/ghc" 9aa94586/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9aa94586fde73e818e32e5cc0e6420f6ed36a80b" Note STM's vulnerability to non-allocating loops Test Plan: Read it Reviewers: austin, fryguybob Reviewed By: austin Subscribers: thomie, fryguybob Differential Revision: https://phabricator.haskell.org/D1523 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/367#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11131: Eta reduction/expansion loop
by GHC 26 Nov '15

26 Nov '15

#11131: Eta reduction/expansion loop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 build log for HEAD today you'll see: {{{ WARNING: file compiler\simplCore\SimplCore.hs, line 604 Simplifier bailing out after 10 iterations [148, 4, 4, 4, 4, 4, 4, 4, 4, 4] Size = {terms: 290, types: 237, coercions: 56} }}} when compiling`Data/ByteString/Builder/Prim/Internal/Floating.hs`. There is a loop here: in each simplifier pass we get an eta-expansion and an eta reduction, which cancel each other out. This is bad. Here is the offending snippet of code {{{ ((bindIO @ () @ () ($fStorableDouble_$cpoke (castPtr @ Word8 @ Double op) x) ((\ (ds :: ()) -> (\ (eta_B1 :: State# RealWorld) -> (k `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) eta_B1) `cast` (Sym (NTCo:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #)) ~R# IO ())) `cast` (<()>_R -> NTCo:IO[0] <()>_R ; Sym (NTCo:IO[0] <()>_R) :: (() -> IO ()) ~R# (() -> IO ())))) `cast` (NTCo:IO[0] <()>_R :: IO () ~R# (State# RealWorld -> (# State# RealWorld, () #)))) }}} At this point `k` is in scope with arity 2. Actually its binding is {{{ k :: IO () k = bindIO @ Word64 @ () a_s2As a_s2Au }}} I'm not precisely sure why this goes wrong, but it's very clearly bogus, so I'm opening a ticket to keep track. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 26 Nov '15

26 Nov '15

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): From the GMP 6.1.0 release notes (released November 1): > * Stack usage trimmed; we believe 512 KiB is now sufficient for any GMP call, irrespective of operand size. So, this should indeed not be an issue for GMP 6.1.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 26 Nov '15

26 Nov '15

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * keywords: exponentiation => gmp -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11133: Misaligned stack leads to dynamic linker crash
by GHC 26 Nov '15

26 Nov '15

#11133: Misaligned stack leads to dynamic linker crash --------------------------------------+---------------------------------- Reporter: trippels | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- {{{ Running programs compiled with ghc leads to a crash of the glibc dynamic linker. This happens because ghc doesn't align the stack correctly during lazy symbol resolution. Example: markus@x4 glibc-build % gdb --args /var/tmp/glibc-build/elf/ld- linux-x86-64.so.2 /home/markus/bin/xmonad Reading symbols from /var/tmp/glibc-build/elf/ld-linux-x86-64.so.2...done. (gdb) run Starting program: /var/tmp/glibc-build/elf/ld-linux-x86-64.so.2 /home/markus/bin/xmonad [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _dl_lookup_symbol_x (undef_name=0x7ffff75cb3c5 "__gmpn_invert_limb", undef_map=0x7ffff76494d0, ref=ref@entry=0x7fffffffa170, symbol_scope=0x7ffff7649828, version=0x0, type_class=type_class@entry=1, flags=1, skip_map=0x0) at dl- lookup.c:809 809 struct sym_val current_value = { NULL, NULL }; (gdb) bt #0 _dl_lookup_symbol_x (undef_name=0x7ffff75cb3c5 "__gmpn_invert_limb", undef_map=0x7ffff76494d0, ref=ref@entry=0x7fffffffa170, symbol_scope=0x7ffff7649828, version=0x0, type_class=type_class@entry=1, flags=1, skip_map=0x0) at dl- lookup.c:809 #1 0x0000555555564413 in _dl_fixup (l=<optimized out>, reloc_arg=<optimized out>) at ../elf/dl-runtime.c:111 #2 0x000055555556ce1f in _dl_runtime_resolve_sse () at ../sysdeps/x86_64 /dl-trampoline.h:112 #3 0x00007ffff762093a in __gmpn_divrem_1 () from /usr/lib/libgmp.so.10 #4 0xee6b280000000000 in ?? () #5 0x00007ffff6b0b138 in ?? () #6 0x00007ffff6b057d0 in ?? () #7 0x00000000ffffffe2 in ?? () #8 0x00007ffff6b057b8 in ?? () #9 0x00007ffff6b051b0 in ?? () #10 0x00007ffff6b0b1b0 in ?? () #11 0x00000000006b47d8 in ?? () #12 0x00000000006142a9 in ?? () #13 0x0000000000000000 in ?? () (gdb) disass Dump of assembler code for function _dl_lookup_symbol_x: ... => 0x000055555555e93a <+154>: movaps %xmm0,-0x80(%rbp) The crash happens because the incoming stack alignment is wrong: rax 0xffffffff 4294967295 rbx 0x7ffff763c360 140737343898464 rcx 0x7ffff75cb3d7 140737343435735 rdx 0x0 0 rsi 0x33f9b936d4fb49a0 3745228210287888800 rdi 0x7ffff75cb3c5 140737343435717 rbp 0x7fffffffa148 0x7fffffffa148 rsp 0x7fffffffa058 0x7fffffffa058 r8 0x0 0 r9 0x1 1 r10 0x7ffff76494d0 140737343952080 r11 0x7ffff7620840 140737343785024 r12 0x0 0 r13 0x0 0 r14 0x7ffff76494d0 140737343952080 r15 0x7fffffffa170 140737488331120 rip 0x55555555e93a 0x55555555e93a <_dl_lookup_symbol_x+154> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 0000000000001470 <_dl_lookup_symbol_x>: 1470: 55 push %rbp 1471: 48 89 e5 mov %rsp,%rbp 1474: 41 57 push %r15 1476: 41 56 push %r14 1478: 41 55 push %r13 147a: 41 54 push %r12 147c: 49 89 d5 mov %rdx,%r13 147f: 53 push %rbx 1480: 49 89 f7 mov %rsi,%r15 1483: 4d 89 c6 mov %r8,%r14 1486: 48 81 ec a8 00 00 00 sub $0xa8,%rsp 148d: 0f b6 17 movzbl (%rdi),%edx 1490: 48 89 bd 68 ff ff ff mov %rdi,-0x98(%rbp) 1497: 48 89 8d 50 ff ff ff mov %rcx,-0xb0(%rbp) 149e: 44 89 8d 5c ff ff ff mov %r9d,-0xa4(%rbp) 14a5: 4c 8b 65 18 mov 0x18(%rbp),%r12 14a9: 84 d2 test %dl,%dl 14ab: 0f 84 cb 02 00 00 je 177c <_dl_lookup_symbol_x+0x30c> 14b1: 48 89 f9 mov %rdi,%rcx 14b4: b8 05 15 00 00 mov $0x1505,%eax 14b9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 14c0: 48 89 c6 mov %rax,%rsi 14c3: 48 83 c1 01 add $0x1,%rcx 14c7: 48 c1 e6 05 shl $0x5,%rsi 14cb: 48 01 f0 add %rsi,%rax 14ce: 48 01 d0 add %rdx,%rax 14d1: 0f b6 11 movzbl (%rcx),%edx 14d4: 84 d2 test %dl,%dl 14d6: 75 e8 jne 14c0 <_dl_lookup_symbol_x+0x50> 14d8: 89 c0 mov %eax,%eax 14da: 48 89 85 60 ff ff ff mov %rax,-0xa0(%rbp) 14e1: 66 0f ef c0 pxor %xmm0,%xmm0 14e5: b8 ff ff ff ff mov $0xffffffff,%eax 14ea: 4d 85 f6 test %r14,%r14 14ed: 48 89 85 78 ff ff ff mov %rax,-0x88(%rbp) => 14f4: 0f 29 45 80 movaps %xmm0,-0x80(%rbp) (0x7fffffffa058 + 0xa8) % 16 == 0 (instead of the correct 8) Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 for further info. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11105: Put the generic-default type in the Class
by GHC 26 Nov '15

26 Nov '15

#11105: Put the generic-default type in the Class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- This is an internal GHC refactoring ticket. Consider {{{ {-# LANGUAGE DefaultSignatures #-} class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> Bool op x y = x < y }}} The `Class` object for `C` has a `ClassOpItem` that specifies * the name `op` * the type of the method `a -> a -> Bool` * that `op` has a generic-default signature BUT it does not contain the actual signature `Ord a => a -> a -> Bool`. That's really wrong; it is certainly part of the definition of the class, and we should print it out when we say `:info C` in ghci. Instead this type is kept solely in the top-level generic-default Id binding. But that means that default-method Ids and generic-default method Ids are treated differently; see `gen_dm_ids` in `tcTyClDecl1` in `TcTyClsDecls`, and `mkDefaultMethodIds` in `TcTyDecls`. We should treat them uniformly. I know how but have too much in flight to do it immediately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11014: re-order GHC type errors for clarity
by GHC 25 Nov '15

25 Nov '15

#11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Here's a typical simple type error from GHC: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ }}} The order of sections is "couldn't match", "expected actual", "relevant bindings", "context" (in the second argument etc.). I think it would be easier to read as "couldn't match", "expected actual", "context", "bindings", and with a * to mark each section: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) }}} I'm sure there are plenty of other sections that don't show up in this simple example, in any case they should go from most to least critical and be marked off with a *. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8