July 2013 - ghc-tickets

Re: [GHC] #7399: Test Posix004 fails in test-suite
by GHC 20 Jul '13

20 Jul '13

#7399: Test Posix004 fails in test-suite ------------------------------------------------+-------------------------- Reporter: paulh | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by ezyang): I've boiled it down to a minimal C test case, it looks like the behavior of processes which receive SIGFPE is acting funny. http://stackoverflow.com/questions/17766149/program-with-sigfpe-exception- behaves-differently-under-gdb -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7399#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7399: Test Posix004 fails in test-suite
by GHC 20 Jul '13

20 Jul '13

#7399: Test Posix004 fails in test-suite ------------------------------------------------+-------------------------- Reporter: paulh | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ezyang): * owner: => ezyang Comment: I can reproduce on Raring Ringtail, and am investigating. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7399#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 20 Jul '13

20 Jul '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ezyang): * difficulty: => Unknown Comment: On latest head, it seems a profiled GHC still segfaults on stg_sel_1_noupd_info. How long until the full fix? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 Jul '13

20 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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): nope, the idea is to provide CMM / Haskell level prim ops. Normal primops. (see my reply on list :) ). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 Jul '13

20 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 rrnewton): Sorry, I was just referring to the proposal to "substitute the cas funcall with the right llvm operation" as rewriting. That is, the approach would pattern match for the CMM code "ccall cas" or "foreign "C" cas" (I'm afraid I don't know the difference between those) and replace it with the equivalent LLVM op, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 Jul '13

20 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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): hrm, I guess you mean the making the CAS ops inline native primops as "rewriting"? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 Jul '13

20 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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): Ryan, could you explain what you mean by "rewriting trick"? I have no idea what you mean. Ryan, could you please explain what primops you want using the terminology / vocabulary in http://llvm.org/docs/LangRef.html#ordering and http://llvm.org/docs/Atomics.html ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 Jul '13

20 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 rrnewton): A couple additional suggestions copied over from the mailing list: (1) we should use more unique symbols than "cas", especially for this rewriting trick. How about "ghc_cas" or something? (2) it would be great to get at least fetch-and-add in addition to CAS and barriers (3) if we reliably provide this set of special symbols, libraries like atomic-primops may use them in the .cmm and benefit from the CMM->LLVM substitutions -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3676: realToFrac doesn't sanely convert between floating types
by GHC 20 Jul '13

20 Jul '13

#3676: realToFrac doesn't sanely convert between floating types --------------------------------------+---------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Changes (by carter): * difficulty: => Unknown Comment: Hrm, so we need a good conversion story / semantics for mapping between different floating point types? This is near and dear to some of my current work, I'll look into coming up with a good story, and if successful, propose it to the libraries list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3676#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 19 Jul '13

19 Jul '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * difficulty: => Unknown Comment: In light of how some other work folks are doing would benefit from this, i'll get this finished up by the close of august -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0