- ghc-tickets - Haskell.org

[GHC] #12558: GHCi Segmentation fault/access violation in generated code
by GHC 28 Nov '16

28 Nov '16

#12558: GHCi Segmentation fault/access violation in generated code ------------------------------+------------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler. The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone. I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff. To try out use a minimal program: {{{#!hs module Main where import Language.Haskell.Tools.Refactor main = demoRefactor "" "." "A" }}} Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root. That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem: {{{#!hs module A where }}} PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12890: Stdcall - treating as CCall (bogus warning on win 64 bit)
by GHC 28 Nov '16

28 Nov '16

#12890: Stdcall - treating as CCall (bogus warning on win 64 bit) -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On windows you generally have the stdcall calling convention so you're average foreign import looks like this: {{{ foreign import stdcall "someFile.h getFoo" getFoo :: IO Foo }}} But on a 64 bit system, GHC warns: {{{ C:\Some\Path.hs:35:1: warning: [-Wunsupported-calling-conventions] * the 'stdcall' calling convention is unsupported on this platform, treating as ccall * When checking declaration: foreign import stdcall safe "static someFile.h getFoo" getFoo :: IO Foo }}} Both stdcall & ccall are not applicable to a 64 bit system as far as I know, and if it was really treating it as ccall it would have segfaulted at runtime. So the warning is a bit of a lie anyway. So far some developers generally have resorted to creating c preprocessor macros like this: [https://www.mail-archive.com/cvs- libraries@haskell.org/msg09725.html] Apologies if this is a dupe, I thought someone already reported this a long time ago but I can't seem to find the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12889: memory leak
by GHC 28 Nov '16

28 Nov '16

#12889: memory leak -------------------------------------+------------------------------------- Reporter: zoranbosnjak | 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: -------------------------------------+------------------------------------- This simple test program leaks memory for no obvious reason. {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} However, there are some minor changes that (each individual change alone) make this program run in constant memory. 1. If I remove {{{#!hs module Main where }}} 2. If I remove recursive call to main 3. If I put task definition under the scope of main, like so {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main where task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} Any of the changes above make the program run OK, but I belive that this should be also true for the original test program. I am not sure where the problem is (if at all), but it's extremely difficult to isolate this kind of problem in the real application. Please check if anything can be done on the compiler or runtime to prevent this kind of problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12889> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12887: Make each RTS header self-contained
by GHC 28 Nov '16

28 Nov '16

#12887: Make each RTS header self-contained -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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: -------------------------------------+------------------------------------- We should make each header in the RTS self-contained – that is, make sure that it is valid when included on its own. Otherwise, some tools (such as the YouCompleteMe semantic completion system for Vim) report spurious errors when editing header files. (Also, not sure if this belongs here, or as a task on Phabricator) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12686: Attempt to promote a value to a type results in an internal error
by GHC 28 Nov '16

28 Nov '16

#12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | 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: -------------------------------------+------------------------------------- Trying to compile {{{#!hs {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = Zero | Succ Nat data Vec :: * -> Nat -> * where Nil :: Vec a 'Zero Cons :: a -> Vec a n -> Vec a ('Succ n) data Bad = Bad { a :: Nat, b :: Vec Int a} }}} results in `error: Not in scope: type variable ‘a’`. Change the last structure to {{{#!hs data Bad = Bad { a :: Nat, b :: Vec Int 'a} }}} and the result is {{{ • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r15Y :-> ATcTyCon Bad, r17P :-> APromotionErr RecDataConPE] • In the second argument of ‘Vec’, namely ‘a’ In the type ‘Vec Int a’ In the definition of data constructor ‘Bad’ }}} The user is attempting to promote a value to a type, which cannot be done, but the error message should be more informative. Reproduces in 8.0.1 and 8.1.20160916. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #618: Dependency caching in ghc --make
by GHC 27 Nov '16

27 Nov '16

#618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): dobenour: SQLite, or really any single file database, could be used, but this would change GHC's compilation model to output some extra files besides the files it normally outputs. I'm a little loathe to do this when we ought to be able to just read out the cached dependencies from the interface files we generate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/618#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 27 Nov '16

27 Nov '16

#5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Have the LLVM devs been asked about this? I think that GHC's use of CPS (and its non-use of the C stack) might be one of the problems. LLVM is designed for C-style code and its optimizations might not fire on the IR that GHC generates. I can think of a solution, but it would involve significant changes, both to the compiler and the RTS. The idea is to do a CPS => SSA transform and then lower to LLVM IR from the SSA form. The Haskell stack would become the C stack, with stack switching handled by the assembler code in `StgRun`. LLVM's GC support would be used to generate stack maps to be read by the RTS for GC purposes. Fortunately, I believe that these tasks are relatively independent. I suspect (from what others have said) that an equivalent of LLVM's `mem2reg` for the STG stack is what is needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5567#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #618: Dependency caching in ghc --make
by GHC 27 Nov '16

27 Nov '16

#618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Could SQLite be used as the storage backend for the cache? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/618#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

27 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 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): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12884: Parsing of literate files fails because of special character (#)
by GHC 27 Nov '16

27 Nov '16

#12884: Parsing of literate files fails because of special character (#) -------------------------------------+------------------------------------- Reporter: bales | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: literate | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A sharp sign (#) in the documentation part of a literate haskell file causes the parser to fail. As I understand it, any line that doesn't start with a greater-than sign should be ignored. {{{#!hs #+ > module Empty where }}} The previous code leads to the following error: with ghc-7.8.3: Bug.lhs:1:2: lexical error at character '+'[[BR]] with ghc-8.0.1: Bug.lhs:1:1: error: parse error on input ‘#+’ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1