March 2016 - ghc-tickets

[GHC] #11772: GHC.CString.unpackCStringUtf8# is inlineable
by GHC 30 Mar '16

30 Mar '16

#11772: GHC.CString.unpackCStringUtf8# is inlineable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- While looking through the logs of a build of a project I have lying around with a GHC 8.0 snapshot, I noticed that there may still be some fragile rules in the `text` package (see #11528 for a previous issue). The problem is that `GHC.CString.unpackCStringUtf8#` may be inlined, which may preempt the `TEXT literal UTF8` rule in `Data.Text.Show`. `unpackCStringUtf8#` doesn't seem like a terribly great candidate for inlining as it produces a list, {{{#!hs unpackCStringUtf8# :: Addr# -> [Char] }}} Moreover, the other functions in this module along these lines (e.g. `unpackCString#` are marked `NOINLINE`. Perhaps this should have a `NOINLINE` pragma as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing
by GHC 30 Mar '16

30 Mar '16

#11688: Bytestring break failing rewrite to breakByte and failing to eliminate boxing/unboxing -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Tyson Whitehead gives a detailed description of the problem [https://github.com/haskell/bytestring/issues/70 here]. Key points: - Program fails to rewrite {{{ ByteString.break (== x) chunk }}} to {{{ ByteString.breakByte x chunk }}} - Missed unboxing opportunity (which led to 34gb additional allocations, which is why he noticed it) I could reproduce the problem on OSX and Windows with GHC 7.10.3. Haven't tested Linux. I repost it here to make sure it doesn't go unnoticed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8731: long compilation time for module with large data type and partial record selectors
by GHC 30 Mar '16

30 Mar '16

#8731: long compilation time for module with large data type and partial record selectors -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc1 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times. This seems to related to how GHC handles a many constructor data type with overlapping field names. the time is nearly the same for building a static module with O1 and O2 {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O2 1 ↵ [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total }}} {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O1 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total }}} heck even with -O0 its slow (though not terrible) {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O0 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total }}} Seems like there might something wrong in how we handle data types like this, the complexity need not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan
by GHC 29 Mar '16

29 Mar '16

#11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: https://github.com/centromere | /ghc-bug-testcase | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you configure the test case like so: {{{ $ cabal configure --enable-tests -fbad }}} The QuickCheck application will hang when executed: {{{ $ ./dist/build/properties/properties --quickcheck-verbose --quickcheck- tests 10 10 9 8 7 6 5 4 3 2 1 10 testCase 1 a: }}} If you compile it without the 'bad' flag, it will execute successfully. The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11756: Data.Functor.Classes instances for Proxy
by GHC 29 Mar '16

29 Mar '16

#11756: Data.Functor.Classes instances for Proxy -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- It looks like Proxy is missing instances for Eq1, Ord1, Show1, and Read1. These are all completely trivial. Can I add them? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11663: GHC 8.0 behavior WRT scoped type variables changed
by GHC 29 Mar '16

29 Mar '16

#11663: GHC 8.0 behavior WRT scoped type variables changed -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Not sure if this was intentional or not. This compiles under GHC 8.0.0.20160221 {{{ module Main where import Control.Exception import System.IO main = writeFile "zzz" "hi" `catch` (\(e :: SomeException) -> return ()) }}} Run with an unwritable file named "zzz" in the directory, it ends without complaint. Run under GHC 7.10.3, it throws an error at compilation time: {{{ code/printPls.hs:8:19: Illegal type signature: ‘SomeException’ Perhaps you intended to use ScopedTypeVariables In a pattern type-signature }}} Did something intentionally change to make this compile out of the box? When I add: {{{ {-# LANGUAGE ScopedTypeVariables #-} }}} Both versions compile. This distinction holds in GHCi as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 29 Mar '16

29 Mar '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: 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 simonpj): Oh sorry, my fault. I stupidly missed the fact that `t` was existential. Just ignore comment:24. So this is an example of the ticket. Back to comment:9 then, I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 29 Mar '16

29 Mar '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: 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 ryantrinkle): Hmm, when I try to convert it to a newtype, like this: {{{ newtype Some tag = forall t. This (tag t) }}} I get this error: {{{ src/Data/Some.hs:17:20: A newtype constructor cannot have existential type variables This :: forall (k :: BOX) (tag :: k -> *) (t :: k). tag t -> Some tag In the definition of data constructor ‘This’ In the newtype declaration for ‘Some’ }}} Is there a different way of converting it to a newtype that I'm overlooking? Here's a link to the original source of that Some: https://hackage.haskell.org/package/dependent-sum-0.3.2.1/docs/src/Data- Some.html#Some . The Hoogle output is more confusing to me than the original. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11769: Support and redistributables for ARM64 (64bit)
by GHC 29 Mar '16

29 Mar '16

#11769: Support and redistributables for ARM64 (64bit) ---------------------------------------+--------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM
by GHC 29 Mar '16

29 Mar '16

#11745: In GHC Download section it is not stated that ARMv7 build is only for 32bit ARM --------------------------------+-------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Documentation bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+-------------------------------------- [https://www.haskell.org/ghc/download_ghc_7_10_3#linux_armv7] I have tried that on ARM64 and it doesn't "configure" because ghc-pwd is 32bit. This waste some time to figure out. If it is stated in the site, that those are 32bit distributions only - it will safe some effort. {{{ ubuntu@geekbox-arm64:~/ghc-7.10.2$ ./configure checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd-bindist: line 3: /home/ubuntu/ghc-7.10.2/utils /ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory configure: error: cannot determine current directory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3