September 2014 - ghc-tickets

[GHC] #9398: Data.List.cycle is not a good producer
by GHC 20 Oct '14

20 Oct '14

#9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Data.List.cycle is not a good producer. I'm not at all sure this solution is the best, but it allocates much less when mapped over and then folded. If we could make it a good consumer cheaply that would be nice too, but I imagine it's probably mostly applied to short lists, so that is probably not a priority. {{{#!hs {-# INLINE cycle #-} cycle :: [a] -> [a] cycle [] = error "Prelude.cycle: empty list" cycle xs = concat $ repeat xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9639: Remove OldTypeable
by GHC 20 Oct '14

20 Oct '14

#9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think it's safe to remove `Data.OldTypeable` now. It's been deprecated in 7.8, and we said that we'd remove it for 7.10. This ticket is to record that task, and to check that there are no objections to removing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9309: Regression when building the 'sizes' application
by GHC 19 Oct '14

19 Oct '14

#9309: Regression when building the 'sizes' application ----------------------------+---------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- I have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): make_exp (App _ (Coercion _)) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_
by GHC 18 Oct '14

18 Oct '14

#9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: Phab:D99 -------------------------------------+------------------------------------- During normal course of action in `real_main` a process is terminated with a call to {{{#!hs shutdownHaskellAndExit(exit_status, 0 /* !fastExit */); }}} which is defined as {{{#!hs void shutdownHaskellAndExit(int n, int fastExit) { if (!fastExit) { // even if hs_init_count > 1, we still want to shut down the RTS // and exit immediately (see #5402) hs_init_count = 1; // we're about to exit(), no need to wait for foreign calls to return. hs_exit_(rtsFalse); } stg_exit(n); } }}} However, when we call `forkProcess`, the child process does ''not'' terminate in this manner, but instead calls {{{#!hs hs_exit(); // clean up and exit stg_exit(EXIT_SUCCESS); }}} instead, where `hs_exit` is defined as {{{#!hs void hs_exit(void) { hs_exit_(rtsTrue); // be safe; this might be a DLL } }}} Crucially, this means that, unlike the parent, the child process ''does'' wait for foreign calls to be terminated (it calls `hs_exit_` with `rtsTrue` instead of `rtsFalse`). I don't see a reason why the child process should terminate in a different manner to the parent, so I propose to change this so that `forkProcess` calls `shutdownHaskellAndExit`, just like `real_main` does. Incidentally, this is the immediate cause for https://ghc.haskell.org/trac/ghc/ticket/9284 , although the patch proposed in this ticket is not sufficient to solve the problems with termination of the I/O manager in the general case (but I will let Andreas explain that in more detail :). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9340: Implement new `clz` inline primop
by GHC 18 Oct '14

18 Oct '14

#9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (CodeGen) | Differential Revisions: Keywords: primop clz | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: {{{#!hs -- | Compute base-2 log of 'Word#' -- -- This is internally implemented as count-leading-zeros machine instruction. foreign import ccall unsafe "integer_gmp_word_log2" wordLog2# :: Word# -> Int# }}} {{{#!c HsWord integer_gmp_word_log2(HsWord x) { #if (SIZEOF_HSWORD) == (SIZEOF_INT) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; #else # error unsupported SIZEOF_HSWORD #endif } }}} Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop ({{{clz# :: Word# -> Int#}}}). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #9604: Python test runner assumes native Python on Windows
by GHC 11 Oct '14

11 Oct '14

#9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- runtests.py assumes that ctypes.windll is always available when running on Windows, but that is in fact only available when using a native Windows Python, but not the mingw/msys Python. The code causes a crash over a trivial issue of setting the terminal to UTF-8 mode. See attached patch for a fix. (The second patch is a cleanup.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9649: symbols should/might be type level lists of chars
by GHC 08 Oct '14

08 Oct '14

#9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 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 thought I had seen that feature request in trac but did not find it. Sorry if I am wrong. A simple use case might be a type safe routing framework, e.g. {{{ get :: Route "/a/:id" $ do idA <- param :: Param "idA" ... }}} I spoke with pedro at hacberlin last weekend and he told me simonp and iavor might tell me where to start looking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9356: scanl does not participate in stream fusion
by GHC 07 Oct '14

07 Oct '14

#9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nomeata came up with a fusing version of a strict `scanl'` in a comment on #9345. It's not entirely clear to me whether that's entirely safe, but a non-strict version of it for `scanl` would be, as both a good producer and good consumer, presumably made efficient using the same sorts of magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to write as a good consumer; only the production side remains to be proved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9