- ghc-tickets - Haskell.org

[GHC] #11410: Quantification over unlifted type variable
by GHC 07 Mar '16

07 Mar '16

#11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | 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 silliness is accepted: {{{ data X (a :: TYPE 'Unlifted) = X }}} I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11675: Monomoprhic code makes ImpredicativeTypes infer an existential type
by GHC 07 Mar '16

07 Mar '16

#11675: Monomoprhic code makes ImpredicativeTypes infer an existential type -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- I realise that ImpredicativeTypes is a problematic extension, but I have found something that looks like an outright bug -- no polymorphism involved: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} module Foo where foo :: IO (Maybe Int) foo = do pure $ case undefined :: Maybe String of Nothing -> Nothing Just _ -> (undefined :: Maybe Int) }}} Produces the following errors: {{{ foo.hs:7:3: error: • Couldn't match type ‘forall a. Maybe a’ with ‘Maybe Int’ Expected type: IO (Maybe Int) Actual type: IO (forall a. Maybe a) • In a stmt of a 'do' block: pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } In the expression: do { pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } } In an equation for ‘foo’: foo = do { pure $ case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) } } foo.hs:11:19: error: • Couldn't match type ‘a’ with ‘Int’ ‘a’ is a rigid type variable bound by a type expected by the context: forall a. Maybe a at foo.hs:11:19 Expected type: forall a. Maybe a Actual type: Maybe Int • In the expression: (undefined :: Maybe Int) In a case alternative: Just _ -> (undefined :: Maybe Int) In the second argument of ‘($)’, namely ‘case undefined :: Maybe String of { Nothing -> Nothing Just _ -> (undefined :: Maybe Int) }’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9699: TH function to list names in scope
by GHC 07 Mar '16

07 Mar '16

#9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I [asked about this on stackoverflow](http://stackoverflow.com/questions/26394199/using- templatehaskell-to-list-all-names-in-a-namespace), and apparently it doesn't exist yet. I want a TemplateHaskell function `variablesInScope :: Q [Name]` that returns a list of the `Name`'s of all the variables in scope. TemplateHaskell obviously has this information available in order to implement functions like `reify :: Name -> Q Info` and `lookupValueName :: String -> Q (Maybe Name)`. So it seems like this might be a pretty simple function to add. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11683: compiled files don't load in ghci
by GHC 07 Mar '16

07 Mar '16

#11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- compiled files don't load in ghci {{{ ghc -DYNAMIC bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> }}} According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html #loading-compiled-code, this should work: {{{ Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking. }}} Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the same thing: {{{ if you say :load Foo in GHCi Foo was compiled with -dynamic: loads Foo.o }}} Interestingly -fobject-code does work: {{{ ghci -ignore-dot-ghci -fobject-code GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Ok, modules loaded: Main. Prelude Main> }}} Unfortunately when I do {{{ ghci -v -ignore-dot-ghci -fobject-code }}} I don't see why it works. It doesn't seem to use just ghc to compile , it also uses gcc, see attached file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4: -fext-core -fno-core behaves funny
by GHC 06 Mar '16

06 Mar '16

#4: -fext-core -fno-core behaves funny ---------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: ---------------------+-------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5: fails if library has main()
by GHC 06 Mar '16

06 Mar '16

#5: fails if library has main() -----------------------+---------------------- Reporter: cwitty | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Wont Fix | Keywords: -----------------------+---------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6: Debugging info confuses runtime linker
by GHC 06 Mar '16

06 Mar '16

#6: Debugging info confuses runtime linker -----------------------------+--------------------- Reporter: simonmar | Owner: sewardj Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.02 Resolution: Fixed | Keywords: -----------------------------+--------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3: DiffArray should be instance of Show
by GHC 06 Mar '16

06 Mar '16

#3: DiffArray should be instance of Show --------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: --------------------------+-------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2: rewrite rules, forall, no -fglasgow-exts
by GHC 06 Mar '16

06 Mar '16

#2: rewrite rules, forall, no -fglasgow-exts --------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: --------------------------------+---------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 06 Mar '16

06 Mar '16

#1: Implicit parameters cause strange behavi -----------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: -----------------------+-------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3/ghc" ade1a461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ade1a461ab4ba3e6de3c4afe9fe9766b7b4e51b3" Fix minimum alignment for StgClosure (Trac #11395) The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0