December 2013 - ghc-tickets

Re: [GHC] #7962: "ghc -e <invalid expression>" should return non-zero exit status
by GHC 05 Dec '13

05 Dec '13

#7962: "ghc -e <invalid expression>" should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by Austin Seipp <austin@…>): In [changeset:"47024b63835e2bc238f88e3e1a5b5927a850e74c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47024b63835e2bc238f88e3e1a5b5927a850e74c" Made ghc -e have a nonzero exit code upon failure (Trac #7962 ) Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7307: Share top-level code for strings
by GHC 05 Dec '13

05 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Yeah, this code is buggy. Here are the problems I can find from a quick pass: * TOP_UNPACK is declared to have a thunk-representation. In that case, it needs to use a `StgThunkHeader`, so that the extra padding required to allow for lock-less thunk update in multithreaded code. * Similarly, it should be given the THU and SRT flags. Since these thunks are emitted into the data section (i.e. are static data), they also need the static flag (like THUNK_STATIC). So really TOP_UNPACK is a bad name. * I am not sure this is a good idea, but it seems like this mechanism could be generalized to variadic THUNK_STATICs, which are essentially THUNK_STATIC but have some payload attached to the end. You don't even have to hard-code the infotable anymore. * The GC code is wrong; TOP_UNPACK should be handled like a THUNK_STATIC. * I know for a fact you're missing this case from a number of other giant switch statements in the RTS. Do a grep. * The generated info table never pushes an update frame to adjust itself. So what happens when a reference to a TOP_UNPACK is inside generated code? I think you will end up repeatedly unpacking the string, though I am not 100% sure here. * As for whether or not your C-- is right, you should double-check it with the old C-- we were generating for handling unpacking per thunk. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2
by GHC 05 Dec '13

05 Dec '13

#8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 ------------------------------+-------------------------------------------- Reporter: heatsink | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: MacOS X Keywords: | Type of failure: GHC doesn't work at all Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8561 | ------------------------------+-------------------------------------------- A recent update to the RTS uses the GCC builtin function `__builtin___clear_cache`. This function was introduced in GCC 4.3. In older GCCs that don't have this builtin function, it's treated as an undefined function, leading to a link-time error. My system has GCC 4.2.1, bundled with XCode 3.2.6. The function is called from `rts/sm/Storage.c`. It seems that x86 architectures don't need a cache flush, so a possible fix is to do nothing on GCC < 4.3.6 on x86 architectures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7307: Share top-level code for strings
by GHC 04 Dec '13

04 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:4 carter]: > Very cool! So this would also be possibly part of a first step towards generally "statically constructing/evaluating" small constant data structures at compile time rather than computing them? I'm not familiar with that piece of GHC as yet, but i'll take a wee look at the patch. The `String` is still created at runtime. But the code that creates a heap object from the static object is no longer duplicated for each string literal in the module. (Hmm, I wonder whether this technique could be generalized for all CAFs, not just top-level strings...) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7307: Share top-level code for strings
by GHC 04 Dec '13

04 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Very cool! So this would also be possibly part of a first step towards generally "statically constructing/evaluating" small constant data structures at compile time rather than computing them? I'm not familiar with that piece of GHC as yet, but i'll take a wee look at the patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7307: Share top-level code for strings
by GHC 04 Dec '13

04 Dec '13

#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Here's an experimental patch that achieves what's described in the ticket. It creates a new closure type, `StgTopUnpack` along with a new info table `stg_TOP_UNPACK_info`. All top-level strings are emitted as 4-word thunks (all thunks need to have the same closure representation), with the address of the static string being stored in the 2nd word. Miraculously, the code works. Binary sizes drop a further ~(2-3)% (on top of size reduction from #8590) and GHC can still bootstrap itself. But there are a few issues that I am having trouble with: 1. I am not sure what closure flags `TOP_UNPACK` should have. 2. I do not think entry code for `TOP_UNPACK` is correct. For starters, I mixed high-level Cmm (argument lists) with low-level Cmm (use of `Sp`). But the whole thing is likely wrong. Could somebody take a quick look? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8592: FunDep error message regression
by GHC 04 Dec '13

04 Dec '13

#8592: FunDep error message regression -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This code (provided by Cale Gibbard) {{{ #!haskell {-# LANGUAGE FunctionalDependencies, FlexibleContexts #-} class C a b | a -> b where foo :: a -> b instance C Integer Integer where foo = id f :: Integer -> String f = foo }}} produced this error message in GHC 7.6: {{{ fundep.hs:10:5: Couldn't match type `Integer' with `String' When using functional dependencies to combine C Integer Integer, arising from the dependency `a -> b' in the instance declaration at fundep.hs:6:10 C Integer String, arising from a use of `foo' at fundep.hs:10:5-7 In the expression: foo In an equation for `f': f = foo }}} but this one with GHC HEAD {{{ FunDepError.hs:11:5: No instance for (C Integer String) arising from a use of ‛foo’ In the expression: foo In an equation for ‛f’: f = foo }}} which seems to be a regression. It may be that either message is fine (it seems to be in this case), In that case, this bug is about the test suite not having a test case for where we do want to see the `When using functional dependencies to combine` message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5821: SPECIALISE fails with a cryptic warning
by GHC 04 Dec '13

04 Dec '13

#5821: SPECIALISE fails with a cryptic warning -------------------------------------------------+------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by mikhail.vorozhtsov): * cc: mikhail.vorozhtsov@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5821#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3625: GHCI doesn't work with dtrace on OS X
by GHC 04 Dec '13

04 Dec '13

#3625: GHCI doesn't work with dtrace on OS X ---------------------------------+------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by lelf): {{{ Betty:cbits lelf$ sudo dtrace -i 'demo- trace{printf("%s",copyinstr(arg0))}' dtrace: description 'demo-trace' matched 1 probe CPU ID FUNCTION:NAME 0 2547 demo_trace:demo-trace rzzzz 1 2547 demo_trace:demo-trace foo 0 2547 demo_trace:demo-trace bar 0 2547 demo_trace:demo-trace bzzzzz }}} Seems to work -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3625#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8595: add fusion RULES for mapMaybe
by GHC 04 Dec '13

04 Dec '13

#8595: add fusion RULES for mapMaybe ------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Currently mapMaybe does not fuse at all. The attached patch implements necessary rules for fold/build fusion in both sides (the result and the second argument) to happen. When fusion does not happen, the function should behave exactly the same as before. This proposal has gone through a discussion in the libraries mailing list: http://www.haskell.org/pipermail/libraries/2013-November/021640.html [Note that the subject of the e-mail thread is wrong, it should mention "Data.Maybe.mapMaybe", not "Data.Map.mapMaybe"] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3