August 2014 - ghc-tickets

[GHC] #9236: hGetContents leads to late/silent failures
by GHC 31 Oct '14

31 Oct '14

#9236: hGetContents leads to late/silent failures ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A common newbie error: {{{ #!haskell withFile "file" ReadMode hGetContents >>= putStr }}} The problem, of course, is that the result of `withFile "file" ReadMode hGetContents` isn't forced until `putStr` is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like `"Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed."` Since the current system apparently puts an `[]` as a temporary marker while waiting to see what the rest of the list will be, I imagine that the fix is as simple as putting the error thunk there instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas
by GHC 31 Oct '14

31 Oct '14

#9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5). It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines
by GHC 30 Oct '14

30 Oct '14

#9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines ----------------------------------+--------------------------------------- Reporter: kraai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- When I load a file that uses Windows-style newlines in WinGHCi, set a breakpoint, run to that breakpoint, and execute ":list", the carets that should underline the breakpoint expression are instead appended to the line. I'll attach a screenshot and the file I loaded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9510: Prelude.!! is not a good consumer
by GHC 28 Oct '14

28 Oct '14

#9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think we can probably do something like this, but I haven't checked the Core yet: {{{#!hs xs !! n | n < 0 = error "Prelude.!!: Negative index" | otherwise = foldr go (error "Prelude.!!: index too large or list empty") xs n where go x _ 0 = x go _ f k = f (k - 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8890: segfault on Windows 7 i386
by GHC 27 Oct '14

27 Oct '14

#8890: segfault on Windows 7 i386 ----------------------------+--------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- This minimal example causes the GHC 7.8.1 i386 RC1 and RC2 binaries to segafult on two different Window 7 machines. It doesn't happen with the x86_64 binaries and it doesn't happen on the one Windows 8.1 machine I tried. {{{ {-# LANGUAGE GADTs #-} module Test1 where data T t where T :: T () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type
by GHC 27 Oct '14

27 Oct '14

#9006: GHC accepts import of private data constructor if it has the same name as the type --------------------------+------------------------------------------------ Reporter: | Owner: Lemming | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ $ cat A.hs B.hs module A (T) where data T = T module B where import A (T(T)) }}} `ghci-7.8.2` accepts module B, whereas `ghci-7.6.3` and `ghci-7.4.2` say: {{{ B.hs:3:11: Module `A' does not export `T(T)' }}} For this bug to happen it is important, that the data constructor has the same name as the type. I.e. if you rename the data constructor to, say, `Cons`, then `ghci-7.8.2` will emit the same error as earlier versions. The bug is not dramatic, since if you try to actually use the imported data constructor then ghc will say {{{ B.hs:20:5: Not in scope: data constructor ‘T’ }}} However this error message is very confusing, because it suggests that `T` is not in scope although you imported it correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result
by GHC 27 Oct '14

27 Oct '14

#9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non- ghci non-llvm ways. For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8345: A more efficient atomicModifyIORef'
by GHC 27 Oct '14

27 Oct '14

#8345: A more efficient atomicModifyIORef' ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `atomicModifyIORef'` is currently defined as: {{{ #!haskell atomicModifyIORef' ref f = do b <- atomicModifyIORef ref (\x -> let (a, b) = f x in (a, a `seq` b)) b `seq` return b }}} This doesn't seem to be the best we can do, though. The following implementation exhibits a speedup of 1.7x (vanilla RTS) / 1.4x (threaded RTS) over the current implementation: {{{ #!haskell atomicModifyIORef' ref f = do b <- atomicModifyIORef ref $ \a -> case f a of v@(a',_) -> a' `seq` v b `seq` return b }}} The differences between this version and the current version are: 1. the lambda is now strict in `f a`, and 2. a new result tuple is no longer being allocated. Is there a good reason why `atomicModifyIORef'` is not already defined this way? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss
by GHC 27 Oct '14

27 Oct '14

#9031: ghc panic: RegAlloc.Liveness.computeLivenss -----------------------------------+--------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have some code where ghc consistently panics with {{{ RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1kek }}} The only reference I can find to that block in the dumped output is here: {{{ REC c1kej: movq $block{v c1keo}_info,(%rbp) movsd 7(%rbx),%vSSE_s1ivM movsd 15(%rbx),%vSSE_s1ivN movq 96(%rbp),%rbx movsd %vSSE_s1ivN,88(%rbp) movsd %vSSE_s1ivM,96(%rbp) testq $7,%rbx jne _c1keo jmp _c1kep c1kpo: movq $block{v c1kej}_info,(%rbp) movq %vI_s1it5,%rbx movq $0,120(%rbp) testq $7,%rbx jne _c1kej jmp _c1kek, }}} There doesn't appear to be any reference to {{{c1kpo}}} either. Unfortunately I don't yet have a test case I can provide; I'll keep working on that. Building with -dcore-lint and -dcmm-lint don't show any extra errors. This is with ghc-7.8.2 using NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9422: EPT caching on --make can make spurious instances visible
by GHC 23 Oct '14

23 Oct '14

#9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is perhaps best demonstrated by way of an example. Suppose we have a package a with the following two modules, with A defining a type class and data type, and I defining an orphan instance. {{{#!hs module A where data A = A class C a where cop :: a -> a }}} {{{#!hs module I where import A instance C A where cop = id }}} Then, when compiling this module: {{{#!hs module N where import A x = cop A }}} I might reasonably expect to be told that the instance `C` is not in scope (since I didn't import `I`, nor did any of my dependencies import `I`). However, suppose I have another module: {{{#!hs module M where import I }}} and I use `--make` to compile both of these modules in one go, with `M` being compiled first (`ghc --make N.hs M.hs` does that for me), then `N` will incorrectly type check and compile! This should not happen. The reason for this behavior is that we do not clear the EPT (external package table) between compilations of a file in batch compilation mode; this saves us from having to repeatedly read instances from the external files. Thus, `M`, having loaded the instances into the EPT when type- checking, `N` will automatically pick them up. Note that `I` and `A` have to be in a separate package; otherwise `--make` puts them in the HPT (home package table) and everything works fine. (Note also that one-shot compilation puts home modules in the EPT, but since that gets thrown out everything is fine as well, although perhaps a user of the GHC API could get bitten by this.) As for the fix, it's probably not right to clear the EPT either, since we get quite good time savings from not having to parse interface files repeatedly. Perhaps we could do something clever by partitioning up the EPT, but maybe it's not worth it and we should keep this bug as a known infelicity until the next time this part of the compiler gets rewritten. I'll submit a test-case (marked as failing) anyhoo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2