May 2014 - ghc-tickets

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Looking at the semantics of LLVM's prefix data concept, it seems like it doesn't map terribly well on to our use-case. Namely, the `prefix` attribute allows you to prepend arbitrary data to the beginning of the symbol's definition. While we would want LLVM to place the symbol's address after info table, naive use of prefix data would produce symbols pointing at the beginning of each function's info table. The documentation suggests that this is supposed to be worked around by beginning the prefix data with a trampoline to jump to the true beginning of the symbol. Given we already have a hack that works, I don't see any good reason to implement this hack. However, when used with another pending LLVM [feature](http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html) allowing an offset to be applied to a symbol's address prefix data will become much more useful. I suggest we hold off on using LLVM's prefix data until this has been implemented. Unfortunately, it seems that the proposal is more than a year old with no activity but I can try to resuscitate it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): I just had a look at the llvm codegen and this looks pretty simple to implement. If I've got some time in the next couple days, I may have a crack at it. On a related note, is there any interest in using the llvm api directly in the back end? If so, I can write up another ticket for that. I suspect that it would result in a bit of a speed up. The easiest method would be to depend on one of the llvm bindings, though I don't know if that's acceptable in ghc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 22 May '14

22 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Nice catch! Perhaps I'll try putting together a patch for this in the coming weeks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 22 May '14

22 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by altaic): * difficulty: => Unknown Comment: It appears that the LLVM IR now includes function prefix data: http://llvm.org/docs/LangRef.html#prefix-data Background: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html http://llvm.org/bugs/show_bug.cgi?id=14080 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20130909/188042.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O
by GHC 22 May '14

22 May '14

#9130: Segmentation fault in ThreadPaused.c:223 when compiled with -O ----------------------------------+---------------------------------- Reporter: twi | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Compiling the following program with {{{ghc --make -fforce-recomp -O Tests}}} gives me a segmentation fault when running the resulting executable whereas without {{{-O}}} it runs to completion. {{{ module Main where import Control.Concurrent.Async main :: IO () main = test 100 test :: Int -> IO () test s = do mapM_ wait =<< mapM b [0 .. s] where b _ = async $ return () }}} valgrind and gdb indicate that an invalid read in threadPaused is causing this: {{{ $ valgrind ./Tests ==17550== Memcheck, a memory error detector ==17550== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17550== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==17550== Command: ./Tests ==17550== ==17550== Invalid read of size 4 ==17550== at 0x46C2BE: threadPaused (ThreadPaused.c:223) ==17550== by 0x48FC72: stg_returnToSched (in /tmp/xxx/Tests) ==17550== Address 0x1f is not stack'd, malloc'd or (recently) free'd ==17550== ==17550== ==17550== Process terminating with default action of signal 11 (SIGSEGV) ==17550== Access not within mapped region at address 0x1F ==17550== at 0x46C2BE: threadPaused (ThreadPaused.c:223) ==17550== by 0x48FC72: stg_returnToSched (in /tmp/xxx/Tests) ==17550== If you believe this happened as a result of a stack ==17550== overflow in your program's main thread (unlikely but ==17550== possible), you can try to increase the size of the ==17550== main thread stack using the --main-stacksize= flag. ==17550== The main thread stack size used in this run was 8388608. ==17550== ==17550== HEAP SUMMARY: ==17550== in use at exit: 76,884 bytes in 34 blocks ==17550== total heap usage: 53 allocs, 19 frees, 81,122 bytes allocated ==17550== ==17550== LEAK SUMMARY: ==17550== definitely lost: 0 bytes in 0 blocks ==17550== indirectly lost: 0 bytes in 0 blocks ==17550== possibly lost: 0 bytes in 0 blocks ==17550== still reachable: 76,884 bytes in 34 blocks ==17550== suppressed: 0 bytes in 0 blocks ==17550== Rerun with --leak-check=full to see details of leaked memory ==17550== ==17550== For counts of detected and suppressed errors, rerun with: -v ==17550== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 3) Segmentation fault (core dumped) }}} {{{ (gdb) run Starting program: /tmp/xxx/Tests warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000046c2be in threadPaused (cap=0x6f5dc0 <MainCapability>, tso=0x7ffff6b05390) at rts/ThreadPaused.c:223 223 switch (info->i.type) { (gdb) info locals frame = 0x7ffff6b050f0 info = 0xf bh_info = 0x4779fe <appendToRunQueue+155> bh = 0x7ffff6b10790 stack_end = 0x7ffff6b05390 words_to_squeeze = 0 weight = 0 weight_pending = 9 prev_was_update_frame = rtsFalse }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9134: ghci: internal error: PAP object entered!
by GHC 22 May '14

22 May '14

#9134: ghci: internal error: PAP object entered! ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ <interactive>: internal error: PAP object entered! (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} I am doing development in ghci as described here: https://github.com/chrisdone/ghci-reload-demo I startup ghci from a cabal sandbox with: `cabal repl --ghc-options="-O0 -fobject-code"` I see this error every once in a while. I do not have a reproducible test case, but if I see this when working on a smaller project I can try to create one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7730: :info and polykinds
by GHC 21 May '14

21 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): In fixing {{{:kind}}} we just have to also tidy the type because currently it's not for some reason. I could patch that by setting {{{-fprint- explicit-foralls}}}, {{{-fprint-expicit-kinds}}} and printing thorough {{{pprTypeForUser}}} but I remember that you mentioned something about removing tidying from {{{pprTypeForUser}}} so I would like some input on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3719: Literate code with #
by GHC 21 May '14

21 May '14

#3719: Literate code with # ----------------------------------------------+---------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by heisenbug): * difficulty: => Unknown Comment: `unlit` already has shebang filtering: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L184 Why not give a `-filter-cpp` option to it, so that all lines with whitespace followed by '#' are filtered out? Then GHC (when invoked with -XNoCPP) would just pass on `-filter-cpp` to `unlit`. My use-case is an `emacs` org-mode document with embedded literate Haskell like this: {{{ #+begin_src literate-haskell > expr2final :: (Arith' repr, Cond repr) => Expr a -> repr a > expr2final (Lit i) = lit' i > expr2final (e `Plus` e') = expr2final e `plus'` expr2final e' > expr2final (e `Cmp` e') = expr2final e `cmp` expr2final e' > expr2final (If c e e') = if' (expr2final c) (expr2final e) (expr2final e') #+end_src }}} This results in the same error {{{ lexical error at character '+' }}} and is pretty annoying. Org-mode expects the '#' int the first column, so indenting does not help here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3719#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9133: Improve parser error reporting in `ghc-pkg`
by GHC 21 May '14

21 May '14

#9133: Improve parser error reporting in `ghc-pkg` ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's what I was confronted recently due to a broken sandbox environment: {{{ $ cabal info parsec cabal: ghc-pkg: Data.Binary.Get.runGet at position 9583: demandInput: not enough bytes }}} The main problem is that this message is not very helpful (other than telling that `ghc-pkg` wasn't able to do something). Duncan told me, that the recent `binary` API now provides better facilities for error reporting. That could be used to improve the UI of `ghc-pkg` when reporting errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384
by GHC 21 May '14

21 May '14

#9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8866 | ------------------------------------+------------------------------------- Found this while working on something else. This is a real bug that can cause random `scavenge_stack` failures at runtime, and could be the cause of #8866. I have a fix on the way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5