November 2014 - ghc-tickets

Re: [GHC] #229: Integer overflow in array allocation
by GHC 10 Nov '14

10 Nov '14

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@… (added) * version: 7.8.1 => 7.9 * milestone: ⊥ => 7.10.1 Comment: Setting milestone per Reid Barton. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 10 Nov '14

10 Nov '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: low => normal * failure: None/Unknown => GHC accepts invalid program * component: GHCi => Compiler (Type checker) * milestone: ⊥ => 7.10.1 Old description: > {{{ > $ compiler/stage2/ghc-inplace --interactive > GHCi, version 6.9.20080317: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude> fmap not (True,True) > > <interactive>:1:0: > No instance for (Functor ((,) Bool)) > arising from a use of `fmap' at <interactive>:1:0-19 > Possible fix: add an instance declaration for (Functor ((,) Bool)) > In the expression: fmap not (True, True) > In the definition of `it': it = fmap not (True, True) > Prelude> :m +Data.Array > Prelude Data.Array> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr > instance Functor ((->) r) -- Defined in Control.Monad.Instances > instance Functor ((,) a) -- Defined in Control.Monad.Instances > instance Functor (Either a) -- Defined in Control.Monad.Instances > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude Data.Array> fmap not (True,True) > (True,False) > Prelude Data.Array> :m -Data.Array > Prelude> :i Functor > class Functor f where fmap :: (a -> b) -> f a -> f b > -- Defined in GHC.Base > instance Functor ((->) r) -- Defined in Control.Monad.Instances > instance Functor ((,) a) -- Defined in Control.Monad.Instances > instance Functor (Either a) -- Defined in Control.Monad.Instances > instance Functor Maybe -- Defined in Data.Maybe > instance Functor [] -- Defined in GHC.Base > instance Functor IO -- Defined in GHC.IOBase > Prelude> fmap not (True,True) > (True,False) > }}} New description: The EPS (external-package state) is only ever increased, never decreased between compilation of different modules in a single batch compilation or GHCi session. Example 1 (GHCi): {{{ ezyang@sabre:~/Dev/labs/ezyangest$ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> (\x -> x) <interactive>:2:1: No instance for (Show (t0 -> t0)) arising from a use of `print' Possible fix: add an instance declaration for (Show (t0 -> t0)) In a stmt of an interactive GHCi command: print it Prelude> :m +Text.Show.Functions Prelude Text.Show.Functions> (\x -> x) <function> Prelude Text.Show.Functions> :m -Text.Show.Functions Prelude> :r Ok, modules loaded: none. Prelude> (\x -> x) <function> }}} Example 2 (make): {{{ ezyang@sabre:~/Dev/labs/ezyangest$ cat A.hs module A where import Text.Show.Functions ezyang@sabre:~/Dev/labs/ezyangest$ cat B.hs module B where y = show (\x -> x) ezyang@sabre:~/Dev/labs/ezyangest$ ghc --make B.hs A.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) ezyang@sabre:~/Dev/labs/ezyangest$ ghc --make A.hs B.hs -fforce-recomp [1 of 2] Compiling B ( B.hs, B.o ) B.hs:2:5: No instance for (Show (t0 -> t0)) arising from a use of `show' Possible fix: add an instance declaration for (Show (t0 -> t0)) In the expression: show (\ x -> x) In an equation for `y': y = show (\ x -> x) }}} -- Comment: I updated the bug description with some modernized, simpler test-cases. simonpj and I have chatted about this and we have a new, improved plan of attack to solve the problem: 1. We'll maintain a set of loaded interface files in the type-checking environment. When an interface file is loaded, we add it to this set. 2. When a type class instance lookup is performed, IF the instance is an orphan, we'll also check if the interface file which defined the instance is in the loaded set. If it is not, we pretend it doesn't exist. I have most of a patch to solve this but I have to shake out a bug where GHCi is not preserving the set of loaded interfaces. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9791: Ghc panics on tiny example, naive try to overload compose
by GHC 10 Nov '14

10 Nov '14

#9791: Ghc panics on tiny example, naive try to overload compose -------------------------------------+------------------------------------- Reporter: camarao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: Overloading | Operating System: Linux Architecture: x86 | Type of failure: Compile- Difficulty: Easy (less than 1 | time crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {-# LANGUAGE MultiParamTypeClasses #-} class Compose a b c e f where (<.>)::(b -> c)->(a -> e)->(a -> f) instance Compose a b c b c where (<.>) = (.) instance Monad m -> Compose a b c (m b) (m c) where (<.>) f g a = g a >>= (return . f) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 10 Nov '14

10 Nov '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: ⊥ Component: GHCi | Version: 6.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: hvr (added) * failure: => None/Unknown Comment: #8427 is related; this ticket is basically the GHCi variant of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8672: :browse and roles on typefamilies
by GHC 10 Nov '14

10 Nov '14

#8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 10 Nov '14

10 Nov '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: System | Keywords: thread-local Resolution: | state, TLS clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: 7678 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by George): Was hoping to have this in the next Haskell Platform. A few months back the patch was coming soon. I assume there were problems. Are we still confident we know how to fix this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9787: typo in the ghci help : 'simplifed'
by GHC 10 Nov '14

10 Nov '14

#9787: typo in the ghci help : 'simplifed' -------------------------------------+------------------------------------- Reporter: nicoder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- Hello, I ran `ghci`at the command line and then `:?` and saw a typo in this line : :sprint [<name> ...] simplifed version of :print (I expected 'simplified' instead of 'simplifed'). Also, the line just above uses the present tense when the other lines use the imperative : :print [<name> ...] prints a value without forcing its computation A search on github ( https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=simplifed ) tells me the typo is probably still in the project source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9643: ghci must be restarted to use break point more than once?
by GHC 10 Nov '14

10 Nov '14

#9643: ghci must be restarted to use break point more than once? -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- When I set a break point (in main say) I stop there when I run the function, but if I run the function again the break point is ignored. Restarting ghci and resetting the break point makes it effective again, but this seems strange. Is this a bug or a feature? Also, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point. Thanks, Dominick -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9666: runtime crashing with +RTS -w -h
by GHC 10 Nov '14

10 Nov '14

#9666: runtime crashing with +RTS -w -h -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: (see Related Tickets: | description) | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A combination of the RTS flags -w and -h makes executables generated with ghc crash at runtime. Does not happen always; my current guess is that a gc run triggers the bug. Reproducible with the following input: '''Main.hs''' {{{#!hs module Main where import qualified Data.Map.Strict as M main = print $ M.lookup 10 $ M.fromList [ (i,i) | i<-[1..10000000] ] }}} {{{ > ghc -rtsopts Main.hs && ./Main +RTS -w -h [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Main: internal error: heapCensus, unknown object: 4093 (GHC version 7.8.3 for x86_64_unknown_linux) }}} optimization level did not change the outcome. I am aware that -w is marked experimental, and I don't need it. Just noticed the crashing. @simon: you get added to Cc (one more time) every time I press "preview", it seems. Doubt that is intentional.. I'll leave you in Cc just so you get this message. (hmm.. where is the bug-tracker bug-tracker..) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1