April 2014 - ghc-tickets

[GHC] #8571: Validation fails
by GHC 02 Nov '14

02 Nov '14

#8571: Validation fails ----------------------------------+--------------------------------- Reporter: khyperia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: | ----------------------------------+--------------------------------- {{{ =====> T5267(normal) 50 of 3812 [0, 0, 0] cd ./arrows/should_compile && 'c:/Users/Evan/Documents/ghc/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-us er-package-db -rtsopts -fno-ghci-history -c T5267.hs >T5267.comp.stderr 2>&1 Compile failed (status 256) errors were: T5267.hs:11:15: tee: standard output: Permission denied }}} followed by an infinite hang. If I comment out that specific test, another test fails a few tests later. If I comment out that one, another one fails a few later. If I comment out *that* one... you get the picture. Running as administrator does not solve the permission denied issue. I am on Windows 8.1, if that matters. I think, I am not sure, that any test with expect_broken in them hangs without moving on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8967: Add syntax for creating finite maps and sets
by GHC 02 Nov '14

02 Nov '14

#8967: Add syntax for creating finite maps and sets ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- Many languages have syntax for creating maps. Commonly used syntax is either {{{ {key1: value1, key2: value2, ...} }}} or {{{ {key1 => value1, key2 => value2, ...} }}} Since few Haskellers (with the notable exception of SPJ) use the curly bracket Haskell syntax for layout, I thought we could co-opt it and instead use it for map (and set literals.) The feature would of course be protected by a language pragma as to not break old code. Strawman proposal: `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, value1), (key2, value2), ...]`, using a new type class: {{{#!haskell class IsMap m where type Key m type Value m fromList :: [(Key m, Value m)] -> m }}} `{:}` is the literal for empty maps. Analogously, `{value1, value2, ...}` desugars to `fromList [value1, value2, ...]`, using a new type class: {{{#!haskell class IsSet m where type Item m fromList :: [Item m] -> m }}} `{}` is the literal for empty sets. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #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] #9038: Foreign calls don't make their arguments look strict
by GHC 21 Oct '14

21 Oct '14

#9038: Foreign calls don't make their arguments look strict ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- Here's a function that takes a `Double` which is always passed to a `foreign import` expecting a `Double#`. Since the value is always unpacked, I'd expect `add3` to be strict in the `Double` argument and thereby avoid some allocation. {{{ add3 :: Distribution -> Double -> Int64 -> State# RealWorld -> (# State# RealWorld, () #) add3 = \ (distrib_a1uw :: Distribution) (val_a1ux :: Double) (n_a1uy :: Int64) (eta_X22 :: State# RealWorld) -> case myThreadId# eta_X22 of _ { (# ipv_i229, ipv1_i22a #) -> case threadStatus# ipv1_i22a ipv_i229 of _ { (# ipv2_i22e, _, ipv4_i22g, _ #) -> case modInt# ipv4_i22g 8 of ww1_i1NM { __DEFAULT -> case distrib_a1uw `cast` (<NTCo:Distribution> :: Distribution ~# Array Stripe) of _ { Array ds2_i22q -> case indexArray# ds2_i22q ww1_i1NM of _ { (# ipv6_i1Nz #) -> case ipv6_i1Nz of _ { Stripe ipv7_s22v ipv8_s22w ipv9_s22x ipv10_s22y -> case {__pkg_ccall main hs_lock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20J ipv9_s22x ipv2_i22e of _ { (# ds4_i20P #) -> case touch# ipv10_s22y ds4_i20P of s'_i20R { __DEFAULT -> case val_a1ux of _ { D# ds6_d1D8 -> case n_a1uy of _ { I64# ds8_d1Da -> case {__pkg_ccall main hs_distrib_add_n Addr# -> Double# -> Int# -> State# RealWorld -> (# State# RealWorld #)}_d1Dd ipv7_s22v ds6_d1D8 ds8_d1Da s'_i20R of _ { (# ds9_d1Db #) -> case {__pkg_ccall main hs_unlock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20m ipv9_s22x ds9_d1Db of _ { (# ds10_i20s #) -> case touch# ipv10_s22y ds10_i20s of s'1_i20u { __DEFAULT -> case touch# ipv8_s22w s'1_i20u of s'2_i1YT { __DEFAULT -> (# s'2_i1YT, () #) } } } } } } } } } } } } } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute
by GHC 19 Oct '14

19 Oct '14

#8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: filepath | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- "Combine two paths, if the second path isAbsolute, then it returns the second.¨ But, the implementation of combine checks if the first character of a path is a path separator, which on Windows is not the same as checking if isAbsolute. This can have counterintuitive results. For example: {{{ import System.FilePath.Windows prop_windows_is_sane :: Bool prop_windows_is_sane = isAbsolute p || ("C:\\STUFF" </> p /= p) where p = "\\foo\\bar" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8683: add "cpp program" and "cpp program options" to settings file
by GHC 14 Oct '14

14 Oct '14

#8683: add "cpp program" and "cpp program options" to settings file ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- so theres a pretty clear consensus that we need to move away from using our c compiler for CPP, so should we add that info to the settings file? I propose adding the following fields to the settings file: "use c compiler cpp", which can have either "YES" or "NO". If "YES", the settings file indicated C compiler is used unless the c compiler selection is overrided by ghc at runtime via -pgmc or -pgmp(p?) if "NO", then the "cpp program" and "cpp program options" fields would be used, unless overridden by -pgmp there'd be some associated patched in the compiler/main/DriverPipeline.hs too i think, but relatively minimal. this would make it much easier to distributed a GHC with its own CPP tool that works -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 69

[GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc
by GHC 07 Oct '14

07 Oct '14

#8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It's mostly a http://www.haskell.org/pipermail/ghc- devs/2014-March/004363.html rechecked on ghc-7.8.1: I attempted to leave original packages as-is. Steps to reproduce: {{{ $ cd /tmp/ $ wget -c http://code.haskell.org/~slyfox/selfcontained-eater- ghc-7.8-rc2.tar.gz $ tar -xzf selfcontained-eater-ghc-7.8-rc2.tar.gz $ cd selfcontained-eater-ghc-7.8-rc2 $ ./mk.sh ... [279 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it }}} I did prepare this testcase for ghc-7.6.3 where it failed only on last 452 module. '''./mk.sh''' is a dumb script calling '''ghc -O2''' + cabal-generated bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4