February 2015 - ghc-tickets

[GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with
by GHC 03 Jul '15

03 Jul '15

#8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- make -j3 fails with Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestar… for details. Stop. make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[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] #8785: Replace hooks API in the RTS with something better
by GHC 16 Jun '15

16 Jun '15

#8785: Replace hooks API in the RTS with something better ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see `compiler/main/SysTools.lhs`) and it apparently doesn't work at all on Mac (#8754). So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (`-rtsopts` etc.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3