- ghc-tickets - Haskell.org

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 05 Dec '13

05 Dec '13

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): I made further 1500 compilation tests and found 5 failures for the unpatched version ghc-7.6.2 and none for my patched ghc-7.6.3 (In my previous comment it was ghc-7.6 instead of ghc-6.8.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:26> 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 parcs): Hah, that's a lot of bugs for such a small patch. Your first point seems to contradict the documentation at https://ghc.haskell.org/trac/ghc/browser/ghc/includes/rts/storage/Closures.…, which says that the usage of `StgThunkHeader` doesn't apply to `THUNK_STATIC`s. Could you clarify this? It seems to me that I could have just given the `TopUnpack` infotable the `THUNK_STATIC` type instead of creating a new closure type. Would you be inclined to agree? Thanks for reviewing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7307#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8577: Polymorphism and typed TH
by GHC 05 Dec '13

05 Dec '13

#8577: Polymorphism and typed TH ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- Consider {{{ data A a = A x = [||A||] y = x :: Q (TExp (A Int)) }}} `$$x` is given type `A a`, as expected. However, `$$y` is also given type `A a`. I would expect it to be `A Int`. In other words, given `p :: Q (TExp T1), $$p :: T2` I think GHC should verify the equation `T1 ~ T2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared
by GHC 05 Dec '13

05 Dec '13

#7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"1860dae3a7e377f085f3a4134f532a7f577fccbe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1860dae3a7e377f085f3a4134f532a7f577fccbe" Suggest TemplateHaskell after encountering a parse error on '$' (#7396) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7396#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared
by GHC 05 Dec '13

05 Dec '13

#7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"0f2a20bc882a918d39219b045a8db1ac7d9354fc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f2a20bc882a918d39219b045a8db1ac7d9354fc" Suggest TemplateHaskell after encountering a naked top-level expression Helps fix #7396 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7396#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Done, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8580: Integer size mismatch errors
by GHC 05 Dec '13

05 Dec '13

#8580: Integer size mismatch errors -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- There is an integer size mismatch in `rts/Stats.c` that causes validation to fail when `size_t /= W_`. This patch adds casts to fix the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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:"69f60722eabcce8283a4270b8d3aff712c8d462a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="69f60722eabcce8283a4270b8d3aff712c8d462a" Add new ghc-e/should_fail test suite Also add a basic test for #7962. Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7962#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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