March 2017 - ghc-tickets

Re: [GHC] #149: missed CSE opportunity
by GHC 18 Mar '17

18 Mar '17

#149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds to me like this is still an issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/149#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5654: Profiling semantics bug
by GHC 18 Mar '17

18 Mar '17

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: merge Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge Comment: I'm going to go ahead and revert 3a18baff06abc193569b1b76358da26375b3c8d6, 2a02040b2e23daa4f791afc290c33c9bbe3c620c, and 394231b301efb6b56654b0a480ab794fe3b7e4db on `ghc-8.2` due to #13433. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #149: missed CSE opportunity
by GHC 18 Mar '17

18 Mar '17

#149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: Is this still an issue, or can we close this ticket? I'm unclear as to the status. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/149#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 18 Mar '17

18 Mar '17

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13439: ForeignPtr finalizers not searched for reachable objects?
by GHC 18 Mar '17

18 Mar '17

#13439: ForeignPtr finalizers not searched for reachable objects? -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: ForeignPtr | Operating System: Unknown/Multiple finalizers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program produces pairs of ForeignPtr's. The finalizer of the second ForeignPtr, uses the first ForeignPtr. When running this program it looks like the first ForeignPtr is finalized before the second one. {{{ import Control.Concurrent import Foreign.Concurrent (newForeignPtr) import Control.Monad import Foreign.ForeignPtr hiding (newForeignPtr) import Foreign.Ptr import System.Mem (performMajorGC) import Data.IORef import Data.Set as Set main = do rFinalized <- newIORef Set.empty forM_ [0..50000] $ \i -> do fp0 <- newForeignPtr nullPtr $ atomicModifyIORef' rFinalized (\s -> (Set.insert i s, ())) newForeignPtr nullPtr $ do finalized <- atomicModifyIORef' rFinalized (\s -> (Set.delete i s, Set.member i s)) when finalized $ putStrLn "fp0 was prematurely finalized" touchForeignPtr fp0 performMajorGC threadDelay 1000000 }}} {{{ $ ghc t.hs [1 of 1] Compiling Main ( t.hs, t.o ) Linking t ... $ ./t fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized }}} Is this a bug in the implementation or an omission in the documentation of `Foreign.Concurrent.newForeignPtr`? Note that a more obvious program behaves correctly. {{{ main = do rFinalized <- newIORef False fp0 <- newForeignPtr nullPtr $ writeIORef rFinalized True newForeignPtr nullPtr $ do finalized <- readIORef rFinalized when finalized $ putStrLn "fp0 was prematurely finalized" touchForeignPtr fp0 performMajorGC threadDelay 1000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC
by GHC 17 Mar '17

17 Mar '17

#13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, {{{ main :: IO () main = do { putStr "hello"; x <- getChar; -- or x <- getLine; putStr "x = "; print x; } }}} the program works in GHCi and after compilation with GHC. in GHCi it works fine but after compilation it does not work fine. in GHCi the first line of code is evaluated the first while after compilation is the second line which is evaluated first. so in GHCi we have as a result: {{{ hellom x = 'm' }}} and after compilation we have as a result: {{{ m hellox = 'm' }}} After compilation, putStr is not evaluated the first. It is getChar or getLine. In GHCi the behavior is correct. But after compilation the behavior is strange. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13440> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13437: Easier editing of multi-line GHCi-commands
by GHC 17 Mar '17

17 Mar '17

#13437: Easier editing of multi-line GHCi-commands -------------------------------------+------------------------------------- Reporter: fredefox | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In my terminal emulator I can write something like: {{{ cat > /dev/null << EOF bla bla bla EOF }}} If I later want to edit something in this command I can recall the command from history and I can navigate to the line I want to change. In GHCi this is not possible, the history only recalls *one line* at a time. It would be nice if it recognized commands entered using {{{ :{ ... }: }}} and would give you that whole command when recalling commands from the history. Also, it would be very handy if doing e.g. Shift+Enter would insert a newline into your multi-line command rather than run the command. Furthermore, it could also serve as a handy shortcut for engaging the multi-line command mode. So say you were sitting at the prompt {{{ > }}} and you then hit enter, then GHCi moves to a new-line but has inserted the {{{ :{ }}} part for you, it could similarly close the command for you when you hit Enter (without holding down the modifier key). I believe this change would make GHCi's multi-line command mode way more useful. Currently I very seldomly (if ever) use GHCi for anything other than one-liners. This means that I usually have to edit the source-file I'm currently working on to put things into scope (or try and formulate a long and awkward expression). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 17 Mar '17

17 Mar '17

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3358 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => phab:D3358 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13436: feature for checking files in temp location
by GHC 17 Mar '17

17 Mar '17

#13436: feature for checking files in temp location -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: ghc-pkg | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-pkg register can do sanity checks on files being in the right place. These are a useful sanity check. The checks can also be disabled with the `--force-files` flag. When installing package files and registering we can either install files and then register or the reverse. The reverse style can be helpful in simplifying the locking system that allows concurrent package installation and use. In particular, new versions of cabal will 1. prepare all package files in a temporary directory; 2. register with ghc-pkg; and 3. use an atomic directory rename to move the package files to their final location This procedure simplifies the locking considerably by not requiring any locks between concurrent package readers and writers, just requiring locks between concurrent writers. Step 2 above requires that we be able to register when the files are not yet in their final location. This can be done with the `--force-files` flag, but we lose out on the useful sanity checks. So this feature request is for a flag that lets us say "do please do the file checks, but instead of looking for files in their final locations, look for them here". Since file paths in the package registration info are usually absolute paths, then the specification of where to look for files would need to be done in terms of changing a prefix. For example, a registration file may contain: {{{ import-dirs: /home/me/.cabal/store/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj }}} And this is used to check for the .hi files for all the modules. But in the above scenario the files will actually all be in /home/me/.cabal/store/**incoming**/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj so we will want to say something like: {{{ ghc-pkg register uniplate.conf \ --file-root=/home/me/.cabal/store/=/home/me/.cabal/store/incoming/ }}} or another example of a slightly different use case would be {{{ ghc-pkg register uniplate.conf \ --file-root=/=$PWD/image/ }}} this is for the case of `--prefix=/usr/local` and `make install DESTDIR=$PWD/image` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13432: ghc: panic! (the 'impossible' happened)
by GHC 16 Mar '17

16 Mar '17

#13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Command** {{{ ghc -c prettystub.hs }}} **Result** {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] hexEscape_a2yj :: t_a2yi[tau:1] (CHoleCan: hexEscape)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5