- ghc-tickets - Haskell.org

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Oct '16

18 Oct '16

#7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12720: Remoce ghcii.sh
by GHC 17 Oct '16

17 Oct '16

#12720: Remoce ghcii.sh --------------------------------------+---------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- On Windows we have an extra script `ghcii.sh` that is recommended when we run in a console that does not use `conhost`. e.g mintty from msys2 or the cygwin shell. This is because the sigINT signal is being swallowed by these consoles. I believe we can work around this by listening to Window messages as well. These consoles do their own drawings, which means they load `gdi32.dll`. Which means they have a message pump so should be receiving Window events. See https://msdn.microsoft.com/en- us/library/windows/desktop/ms686016(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12681: Missing fields warning when qualified records are initialized with unqualified field names
by GHC 17 Oct '16

17 Oct '16

#12681: Missing fields warning when qualified records are initialized with unqualified field names -------------------------------------+------------------------------------- Reporter: lyxia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code leads to a misleading warning. {{{#!hs -- A.hs module A where data A = A { a :: Int } -- B.hs module B where import qualified A x = A.A { a = 0 } }}} GHC warns {{{ A.hs:5:5: warning: [-Wmissing-fields] • Fields of ‘A.A’ not initialised: a • In the expression: A.A {a = 0} In an equation for ‘x’: x = A.A {a = 0} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11108: Weak references related crash
by GHC 17 Oct '16

17 Oct '16

#11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #12722: Compile bug when upgrading stack-1.2.0 on Mac OS X
by GHC 17 Oct '16

17 Oct '16

#12722: Compile bug when upgrading stack-1.2.0 on Mac OS X -------------------------------------+------------------------------------- Reporter: pisomojado | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- output from stack upgrade: {{{ michael@gelato:~/Code/autorefactorer-site$ stack upgrade Fetching package index ...remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), done. Fetched package index. Populated index cache. store-core-0.2.0.2: configure store-core-0.2.0.2: build http-client-0.5.3.1: configure http-client-0.5.3.1: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build path-0.5.8: configure path-0.5.8: build store-core-0.2.0.2: copy/register th-lift-instances-0.1.7: configure path-0.5.8: copy/register th-lift-instances-0.1.7: build path-io-1.1.0: configure path-io-1.1.0: build th-lift-instances-0.1.7: copy/register th-orphans-0.13.1: configure path-io-1.1.0: copy/register th-orphans-0.13.1: build unicode-transforms-0.1.0.1: configure unicode-transforms-0.1.0.1: build unicode-transforms-0.1.0.1: copy/register optparse-applicative-0.13.0.0: copy/register th-orphans-0.13.1: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-simple-0.0.3: copy/register http-client-0.5.3.1: copy/register http-client-tls-0.3.0: configure http-client-tls-0.3.0: build http-client-tls-0.3.0: copy/register http-conduit-2.2.0: configure http-conduit-2.2.0: build th-utilities-0.2.0.1: copy/register store-0.2.1.2: configure store-0.2.1.2: build http-conduit-2.2.0: copy/register store-0.2.1.2: copy/register stack-1.2.0: configure [1 of 1] Compiling Main ( /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/Setup.hs, /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.2.0... stack-1.2.0: build Preprocessing library stack-1.2.0... [ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 96] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc20328_0/libghc_55.dylib, 5): no suitable image found. Did find: /var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc20328_0/libghc_55.dylib: malformed mach-o: load commands size (47024) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 14 action(s). -- While building package stack-1.2.0 using: /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12722> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 16 Oct '16

16 Oct '16

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): See also #11758, where a failed attempt was made to delete the hack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 16 Oct '16

16 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => cpp * os: Unknown/Multiple => MacOS X -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 16 Oct '16

16 Oct '16

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12701: Eta reduce type synonyms when possible
by GHC 16 Oct '16

16 Oct '16

#12701: Eta reduce type synonyms when possible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you can eta reduce a type synonym, it is always better: {{{ -- Bad type F a = Maybe a instance Functor F -- illegal, partially applied type synonym! -- Good type F = Maybe instance Functor F -- ok with type synonym instances }}} So... GHC should do this automatically for users. Ordinarily this is not terribly important (thus the priority); in the context of #12680 it is a modestly helpful affordance which allows a user to implement `data Map a` using `type Map a = HashMap a` (signature matching requires the type synonym to be nullary.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib
by GHC 16 Oct '16

16 Oct '16

#9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`. {{{ module Main where import qualified Codec.Compression.Zlib as Zlib import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Internal as BI import Control.Exception (bracket) import Control.Concurrent import Control.Monad import Control.Exception ( evaluate) import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package import Control.Concurrent.Async ( mapConcurrently) import System.Mem ( performGC ) import Debug.Trace test :: Int -> IO String test _ = do tid <- myThreadId -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100 -- Could also be replaced by: (BL.take (10^7) "/dev/urandom") dat <- BL.readFile "/tmp/testdata" let cbuf = Zlib.compress $ traceChunks tid $ dat s <- evaluate $ sha1 $ Zlib.decompress $ cbuf return $ show s where -- We used this to check whether buffers were reused by different threads, but that -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it -- harder to reproduce possibly because of scheduler effects. In a much larger program -- it could be reproduced more easily without the trace, but in this small example -- tracing seems to cause the right amount of nondeterminism. traceChunks tid bs = BL.fromChunks $ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..] $ BL.toChunks bs showBS (BI.PS ptr off len) = show ptr main = do r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int]) putStrLn $ show $ r where -- Regularly forcing the GC makes the test-case more reproducible. withGCThread io = bracket (forkIO $ forever $ performGC >> threadDelay 1000) killThread (const io) }}} The output should be something like: {{{ ... ThreadId 51:0x00000001091ee010 ThreadId 49:0x00000001091a7010 ... ThreadId 49:0x000000010986f010 zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check) }}} You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different. So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9