April 2015 - ghc-tickets

[GHC] #9675: Unreasonable memory usage on large data structures
by GHC 03 Jul '15

03 Jul '15

#9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have attached a file that, when compiled, results in very large amount of memory usage by GHC. The memory used is in the order of tens of gigabytes, but I've not been able to successfully compile the file due to lack of physical memory. This is on Debian GNU/Linux (Jessie) using Haskell Platform 2014.2.0.0 with GHC 7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10006: Add baseline ellipsis as unicode alternative to «..»
by GHC 03 Jul '15

03 Jul '15

#10006: Add baseline ellipsis as unicode alternative to «..» -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While the current unicode syntax is overall very pleasing to the eye, writing the ellipsis as two periods («..») sticks out quite noticably. I would welcome it if the horizontal ellipsis (U+2026, «…») would be allowed in places where «..» can be written. I noticed that there was an old discussion on the mailing list which indicated that originally there was a unicode replacement for «..», namely the midline ellipsis, which wasn’t considered a good choice and was removed from the syntax. The regular ellipsis would have the advantage that it is one of the more common «fancy» characters and mapped by default in the X server compose definitions; as such it’s rather well-accepted and sees use even on IRC and in blogs. So user’s would potentially benefit from the regular ellipsis, much more so than the more exotic midline ellipsis. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9119: Additional symbols for XUnicodeSyntax
by GHC 03 Jul '15

03 Jul '15

#9119: Additional symbols for XUnicodeSyntax -------------------------------------------+------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.2 Keywords: unicode | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- So, one of the things I love about Haskell is how relatively mathematically friendly it is. To that end, I propose the following additional unicode operators be added to XUnicodeSyntax: "⊦ p → x" for "let p in x" "≝" "≜" "≛" "≚" "≙" "≟" "⇔" "≐" "≞" be added as synonyms for "=" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9977: Nicer imports
by GHC 03 Jul '15

03 Jul '15

#9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: imports | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi, I wonder if we could have {{{#!hs import Data A B (ba, bb, bc) C as C C1 as C1 (ca,cb,cc) D qualified E as E qualified F as F qualified (fa, fb, fc) Libs.Other -- Data.E qualified as E -- both valid -- Data.F qualified as F (fa, fb, fc) }}} to desugar to {{{#!hs import Data.A import Data.B (ba, bb, bc) import Data.C as C import qualified Data.D import qualified Data.E as E import qualified Data.F as F (fa, fb, fc) import Libs.Other }}} so we could make syntax more dry? What it does if there is indentation it uses previous levels as prefix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8363: Order matters for unused import warnings when reexporting identifiers
by GHC 01 Jul '15

01 Jul '15

#8363: Order matters for unused import warnings when reexporting identifiers ------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier. Reproduction: {{{ module Foo ( (<$>) , g ) where import Control.Applicative g :: Int g = 1 }}} {{{ module Main where import Control.Applicative import Foo main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ $ ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} If Main is not using `g` then this gives a warning that the import of `Foo` is redundant. If we switch the order of the imports we do get the warning: {{{ module Main where import Foo import Control.Applicative main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ > ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:4:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() Linking Main ... }}} I expected both versions of Main to produce the same warning. Tested on GHC 7.7.20130824 and 7.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8222: CTYPE pragma on newtype is ignored
by GHC 01 Jul '15

01 Jul '15

#8222: CTYPE pragma on newtype is ignored --------------------------+------------------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ User's guide includes an example where a CTYPE pragma is used for a newtype. {{{ newtype {-# CTYPE "useconds_t" #-} T = ... }}} However, in the following program, the CTYPE pragma seems to be ignored: {{{ {-# LANGUAGE CApiFFI #-} import Foreign.Ptr foreign import capi unsafe "sys/socket.h CMSG_DATA" c_CMSG_DATA :: Ptr Cmsg -> Ptr a newtype {-# CTYPE "sys/socket.h" "struct cmsghdr" #-} Cmsg = Cmsg () main = return () }}} Save this as {{{capi.hs}}}, then compile it like: {{{ ghc capi.hs -fforce-recomp -keep-tmp-files -tmpdir . }}} Then GHC creates a C file: {{{ #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include <sys/socket.h> void* ghczuwrapperZC0ZCmainZCMainZCCMSGzuDATA(void* a1) {return CMSG_DATA(a1);} #ifdef __cplusplus } #endif }}} The argument type of the wrapper function is {{{void *}}}, but it should be {{{struct cmsghdr *}}}. If I replace {{{newtype}}} with {{{data}}} in capi.hs, the wrapper function gets the correct type. I can see this problem in HEAD and in 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used
by GHC 29 Jun '15

29 Jun '15

#10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1-rc1 System | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9423 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this: {{{#!hs import Control.Concurrent import System.Posix.Signals main :: IO () main = do _ <- flip (installHandler sig) Nothing $ Catch $ putStrLn $ "Received signal " ++ show sig raiseSignal sig threadDelay 100000 where sig = sigUSR2 }}} If you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output: {{{ Received signal 12 Received signal 12 Received signal 12 Received signal 12 Received signal 12 }}} In general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals. This regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later [changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted] but then [changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re- added]), a commit addressing #9423. The cause of the problem is [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L183 here])? Removing the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8144: Interface hashes include time stamp of included .h file when CPP is used
by GHC 25 Jun '15

25 Jun '15

#8144: Interface hashes include time stamp of included .h file when CPP is used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- See https://github.com/nh2/ghc-bug-time-dependent-interface-hashes for a fast test case. Having '''Test.hs''': {{{ {-# LANGUAGE CPP #-} module Test () where }}} and an empty '''cabal_macros.h''', {{{ touch cabal_macros.h ghc -c Test.hs -optP-include -optPcabal_macros.h }}} will generate you a different interface hash ''most of the time'' in '''ghc --show-iface Test.hi'''. It looks like the modification time of the .h file makes it into the interface hash, but only at second resolution, and you get ''compilation IS NOT required'' if you manage to run it twice per second. I think the interface hash should be independent from the time stamp of the header file. This bug can trigger unnecessary recompilation and makes compilations with identical inputs non-deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X
by GHC 25 Jun '15

25 Jun '15

#10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- joelteon encountered this issue in a rather complicated program, and we worked out the cause over IRC. Suppose that ghci needs to sequentially load three modules A, B and C, where B refers to symbols from A and C refers to symbols from both A and B. (For example modules B, C and another module D all contain Template Haskell that refers to the previous module(s).) The object code linker currently works like this: - Link the module `A.o` into a dylib `ghc_1.dylib` - Link the module `B.o` against `ghc_1.dylib` into a new dylib `ghc_2.dylib` - Link the module `C.o` against `ghc_2.dylib` into a new dylib `ghc_3.dylib` As a result, `ghc_2.dylib` ends up with a NEEDED (or whatever it's called in Mach-O) entry for `ghc_1.dylib`, and `ghc_3.dylib` ends up with a NEEDED entry for `ghc_2.dylib`. However, this apparently does not satisfy the OS X `dlopen` implementation, which complains about a missing symbol `_A_foo` referenced by `ghc_3.dylib` and which is defined in `ghc_1.dylib`. Apparently the dynamic loader only checks the direct dependencies when trying to resolve undefined symbols. (The Linux dynamic loader seems to be perfectly happy to use an indirect dependency to resolve an undefined symbol. But I found out that the linker [https://sourceware.org/bugzilla/show_bug.cgi?id=10238 gold] has the same sort of behavior as the OS X dynamic loader. I don't know whether there is any standard here, but it seems that we cannot rely on the Linux dynamic loader's behavior.) Presumably the fix is to keep track of all the previous temporary dylibs (rather than just one in `last_temp_so`) and link against all of them when building a new temporary dylib. I'm slightly worried about quadratic behavior here, but I think it's unlikely to be an issue in practice. I have a reproducer at http://lpaste.net/808723564239781888 (which I'll add to the test suite next) and oherrala ran the test on an OS X system with the following results: {{{ =====> Last(ghci) 1167 of 4480 [0, 0, 0] cd ./ghci/scripts && HC="/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history " "/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <Last.script > Last.run.stdout 2> Last.run.stderr Actual stderr output differs from expected: --- /dev/null 2015-04-18 17:23:26.000000000 +0300 +++ ./ghci/scripts/Last.run.stderr 2015-04-18 17:23:34.000000000 +0300 @@ -0,0 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.11.20150418 for x86_64-apple-darwin): + Loading temp shared object failed: dlopen(/var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib, 5): Symbol not found: _LastA_a_closure + Referenced from: /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + Expected in: flat namespace + in /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + Actual stdout output differs from expected: --- ./ghci/scripts/Last.stdout 2015-04-18 16:26:55.000000000 +0300 +++ ./ghci/scripts/Last.run.stdout 2015-04-18 17:23:34.000000000 +0300 @@ -1,3 +1,2 @@ 3 4 -7 *** unexpected failure for Last(ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more
by GHC 22 Jun '15

22 Jun '15

#10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As Iavor confirmed (https://mail.haskell.org/pipermail/ghc- devs/2015-April/008885.html) there is a regression on HEAD relative to `ghc-7.11.20150215`. Here is a reproduction snippet: {{{#!hs {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, StandaloneDeriving #-} import GHC.TypeLits import Data.Typeable data Foo (n :: Nat) where Hey :: KnownNat n => Foo n deriving instance Show (Foo n) data T t where T :: (Show t, Typeable t) => t -> T t deriving instance Show (T n) }}} With ghci-7.11.20150407 I now see more constraints {{{ *Main> :t T Hey T Hey :: (Typeable n, KnownNat n) => T (Foo n) }}} OTOH ghci-7.11.20150215 only wanted `KnownNat`: {{{ *Main> :t T Hey T Hey :: KnownNat n => T (Foo n) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10