March 2015 - ghc-tickets

[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] #10194: Shouldn't this require ImpredicativeTypes?
by GHC 18 Jun '15

18 Jun '15

#10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program compiles: {{{ {-# LANGUAGE RankNTypes #-} module TestRN1 where type X = forall a . a comp :: (X -> c) -> (a -> X) -> (a -> c) comp = (.) }}} But this one fails: {{{ {-# LANGUAGE RankNTypes #-} module TestRN2 where comp :: ((forall a . a) -> c) -> (a -> (forall a . a)) -> (a -> c) comp = (.) }}} Error: {{{ Cannot instantiate unification variable ‘b0’ with a type involving foralls: forall a1. a1 Perhaps you want ImpredicativeTypes In the expression: (.) In an equation for ‘comp’: comp = (.) }}} I would expect both to fail. Both seem to rely on impredicative types. I wouldn't expect expansion of a type synonym to make a difference between a type-checking program and one that does not typecheck. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10131: improve error message for build on noexec-mounted device
by GHC 17 Jun '15

17 Jun '15

#10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- i was building (in a sandbox) on a ramdisk that was accidentally mounted with the noexec flag. for example during the install of `vector`, you get an error like Loading package primitive-0.5.4.0 ... <command line>: can't load .so/.DLL for: somepath/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so (somepath /.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so: failed to map segment from shared object) relevant output of `mount`: none on somepath type tmpfs (rw,nosuid,nodev,noexec,relatime,gid=103,user=lspitzner) this is by far no minimal test-case, but i hope my description of the problem is sufficient. if not, i can provide verbose output for my or other test-cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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

[GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance
by GHC 14 Jun '15

14 Jun '15

#9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running a program like this: {{{#!hs main :: IO Int main = return 5 }}} With `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior: {{{ $ runghc Main.hs 5 $ ghc Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main $ }}} This is the same as `ghci`'s behavior with an IO action, so presumably `runghc` is taking a shortcut here. But a program should behave the same way in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide
by GHC 14 Jun '15

14 Jun '15

#9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide -------------------------------------+------------------------------------- Reporter: Dangthrimble | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Difficulty: Unknown | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Context: I am relatively new to Haskell and am trying to build a Haskell IDE around `Sublime Text`. I have been using `Haskell Platform` but have encountered a number of problems using `cabal`. Consequently I have been advised to uninstall `Haskell Platform` and download `ghc`. I have just downloaded and extracted `ghc-7.8.3-x86_64-unknown- mingw32.tar.xz`. Hoping for advice on setting up `ghc`, I have opened `ghc-7.8.3\doc\html\index.html` in Firefox and clicked on "The User's Guide". Unfortunately the `ghc-7.8.3/doc/html/users_guide` folder is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files
by GHC 14 Jun '15

14 Jun '15

#8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files ------------------------------------+---------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: ghc-pkg race | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages. I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache. In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated) The FreeBSD ports system is used to drive the Haskell build system. The process works single threaded and fails intermittently when done in parallel. Building: devel/hs-data-default-instances-base Building: devel/hs-data-default-instances-containers Building: devel/hs-data-default-instances-old-locale Built: devel/hs-dlist Building: devel/hs-data-default-instances-dlist Built: devel/hs-temporary Built: jail-image-full Installing: system-image__jail-image-full Built: devel/hs-base64-bytestring Built: archivers/hs-zlib Building: security/hs-digest Built: devel/hs-syb Building: textproc/hs-hs-bibutils Building: textproc/hs-pandoc-types Built: devel/hs-utf8-string Built: devel/hs-data-default-instances-old-locale Built: devel/hs-data-default-instances-containers Built: devel/hs-data-default-instances-base Built: devel/hs-data-default-instances-dlist Building: devel/hs-data-default Built: devel/hs-random Installed: system-image__lang/ghc Installing: system-image__archivers/hs-zlib Installing: system-image__devel/hs-utf8-string Installing: system-image__devel/hs-syb Installing: system-image__devel/hs-base64-bytestring Installing: system-image__devel/hs-data-default-class Installing: system-image__devel/hs-dlist Installing: system-image__devel/hs-random Installing: system-image__devel/hs-temporary Installing: system-image__devel/hs-extensible-exceptions Built: devel/hs-data-default FAILED The error from the Haskell data-default build was: setup: At least the following dependencies are missing: data-default-instances-base -any Looking in the in the package.conf.d directory shows that the data- default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default- instances-base Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances- base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base. To me this looks like a race condition between multiple instances of ghc- pkg causing the cache to become inconsistent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9511: Remove deprecated -fglasgow-exts from NoFib suite
by GHC 14 Jun '15

14 Jun '15

#9511: Remove deprecated -fglasgow-exts from NoFib suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: low | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1