August 2013 - ghc-tickets

Re: [GHC] #3353: Add CLDouble support
by GHC 22 Aug '13

22 Aug '13

#3353: Add CLDouble support -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 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 refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3353#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8148: ./configure IGNORES --with-gcc=gcc-4.8
by GHC 22 Aug '13

22 Aug '13

#8148: ./configure IGNORES --with-gcc=gcc-4.8 ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Im seeing the build scripts using gcc instead of gcc-4.8 this is problematic! with xcode 5, gcc IS an old version of clang! attaching a copy of the build log. i'm using 7.6.3 to build this, and the ghc 7.6.3 settings file is pointing to gcc-4.8, so it can only be the build system. I think {{{ [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "gcc-4.8"), ("C compiler flags", " -m64 -fno-stack-protector -m64"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "@ArSupportsAtFile@"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSDarwin"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "True"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} is host 7.6.3 ghc setup -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Most of these patches LGTM, but I haven't reviewed the parallel upsweep patch itself very closely yet. I left a few comments on the others, mostly echoing Simon about some additional documentation, and dead code removal. But this looks like it can easily make the 7.8.1 window, however. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): `errorMsg` just calls `log_action` which will append the stringified exception to the module's `LogQueue` as with any other compile message, so it should be OK. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Ah, good, it sounds like you've handled exceptions carefully. I missed the "try" on line 133 in my first cursory look. https://github.com/parcs/ghc/blob/0aaeb70aa3291cf2ab90af150c3790cf4981db2a/… I was expecting something right after the fork. But it looks like the only code that happens outside of that "try" is the newIORef, putMVar, and writeLogQueue... reasonably safe. Regarding printing, I guess ErrUtils.errorMsg is thread-safe? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Thanks for reviewing! Thanks Simon. I will attempt to comment the changes more sufficiently, following the mentioned coding style. I will update the user manual as well. Ryan: I don't see where a stray exception could occur. The call to `parUpsweep_one` is already guarded by a `try`, and asynchronous exceptions are masked throughout the rest of the worker body. And the rest of the worker body doesn't seem to do anything that could throw an exception from within. So it seems to me that the exception handling is already fairly tight: a worker thread should always exit gracefully. I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 22 Aug '13

22 Aug '13

#8039: RTS linker: unloadObj() does not actually unload the code --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: rts/linker_unload | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * testcase: => rts/linker_unload * resolution: => fixed Comment: Now fixed: 0717462d7724bfe904cffda5706dd74d0b31b883/ghc, 4b94f0c757dd924ba104172e9323b521e689b837/testsuite -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 22 Aug '13

22 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Thanks for doing the work on this! Very exciting. I for one will start testing it. I started reading the code a bit and have one question. But first, thanks for producing well-documented code---very readable! My question has to do with the banal issue of printing stuff out in parallel, which can often be quite ugly. I like that the normal compilation output is directed to a per-module TQueue. But what about printed exceptions when they occur? I see that you've got three "[g]bracket" calls in the parallel upsweep, and that you take care to kill worker threads (asychronously) when an exception occurs. However, I don't see a general catch-all for exceptions at the top of each worker thread (such as in Control.Async). In my experience exceptions on child threads can be a real pain. For example, if a worker thread dies... it looks like other threads may be blocked indefinitely waiting on the result MVar? Apologies if I've missed something... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7958: 'Cannot continue after interface file error' during compilation
by GHC 22 Aug '13

22 Aug '13

#7958: 'Cannot continue after interface file error' during compilation ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Fuuzetsu): Sorry for tardiness, I'm having issues building HEAD. I'll let you know how it went once I get it going again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7958#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 22 Aug '13

22 Aug '13

#8039: RTS linker: unloadObj() does not actually unload the code -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 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 simonmar): Not ready to close yet: the linker doesn't work when `DYNAMIC_GHC_PROGRAMS` is on. I can't think of a reason for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0