January 2016 - ghc-tickets

[GHC] #10873: Bad error message for incorrect pattern synonym signature
by GHC 29 Feb '16

29 Feb '16

#10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program {{{ {-# LANGUAGE PatternSynonyms #-} pattern Pat :: Show a => () => a -> Maybe a pattern Pat a = Just a }}} GHC complains that {{{ test.hs:4:9: No instance for (Show a) arising from a pattern }}} I think this is quite difficult to understand. The problem is that matching on `Just a` doesn't provide the show constraint (it provides no constraints). A better error message here would explain this fact and maybe a short explanation of the difference between prov/req in a pattern synonym signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy"
by GHC 29 Feb '16

29 Feb '16

#11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: #11369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These redundant constraint warnings being in -Wall make it seemingly impossible for us to live up to the '3 Release Policy' in many situations. https://prime.haskell.org/wiki/Libraries/3-Release-Policy Consider the AMP: `(Monad m, Functor m)` gets used as a replacement for `Monad m` in many situations for compatibility with code before GHC 7.8, where that wants to call both `fmap` and something from `Monad`, but from 7.10+ that `Functor` is a redundant constraint. We have no backwards- facing 3-release-compatible constraint that someone could use in a type signature without warning to get both `fmap` and `return` that won't trigger this warning. Similarly if we split a class we can't advocate that folks use the subclass until the superclass is widely available or they'll get spammed with warnings. This affects splitting out `Semigroup` from `Monoid`. A similar issue arises with the `MonadFail` proposal as there is a stage around 8.4 where the 3-release-compatible advice would be to incur a `MonadFail` constraint, even when the active desguaring will be through `Monad`. I don't actually have a fix from the libraries side for the fact that with these showing up in -Wall, the 3 release policy doesn't work. Every single proposal the core libraries committee currently has in the works (except for adding `log1p`, `expm1`, etc. to Floating) is affected by this concern. One possible fix is to demote the redundant superclass warnings out of `-Wall`. This would resolve #11369 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #11134: Limit frequency of idle GCs
by GHC 29 Feb '16

29 Feb '16

#11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | 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: -------------------------------------+------------------------------------- In a server process with a relatively large heap (100s of MB) serving regular but relatively infrequent requests (~1 per sec) the idle GC runs after essentially every request which turns out to be extremely expensive: switching it off takes us from ~30% CPU to ~0.3% CPU. It is certainly useful have the GC run when idle but running it *every* time the process goes idle isn't necessary. It doesn't work to increase the delay (e.g. say -I2) as then the idle GC would never run, because the requests are rather regular. I'd quite like to be able to say something of the form "do a GC if idle for at least 0.3s as long as the idle GC has not run in the last 120s" - where 120s is another option passed to the RTS. Does this sound like a reasonable idea? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9043: Add missing type class instances for data types in GHC.Generics
by GHC 28 Feb '16

28 Feb '16

#9043: Add missing type class instances for data types in GHC.Generics ------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #10316: Move Typeable type-rep generation from use site to definition site
by GHC 27 Feb '16

27 Feb '16

#10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This ticket is a continuation of #9858. The interim solution for 7.10 was to generate `Typeable` data structures on the fly, as needed in client modules. This ticket is about moving the generation of the runtime representation of type constructors to their definition sites. (#9858 already has too much going on in it, so I started a fresh ticket for this refactoring.) The branch is `wip/T9858-typeable-spj`. In favour of (A) code at use site (as in 7.10): * Pay as you go. No code at all is generated unless you use `Typeable` In favour of (B) code at definition site: * More sharing. We make a `TyCon` (see `Data.Typeable.Internal`) for `T` (say) just once, in the module that defines `T`. * We may ultimately want the `TyCon` for `T` to include its source location, and perhaps more besides. If it is defined in `T` it becomes easier to do that. General observation: (B) is like `Typeable` was before, when it was an ordinary class. The difference now is that all types are `Typeable`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8710: Overlapping patterns warning misplaced
by GHC 27 Feb '16

27 Feb '16

#8710: Overlapping patterns warning misplaced -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: low | Version: 7.7 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider {{{ {-# OPTIONS_GHC -fwarn-overlapping-patterns #-} len [] = 0 len (_:t) = 1 + len t len _ = error "urk" }}} GHC reports the problem with this definition at the first line of it. I think it would be more helpful to have it at the last line, which is the pattern that will never match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set
by GHC 27 Feb '16

27 Feb '16

#9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- to reproduce put {{{ main= putStrLn "hello world" }}} in hello.hs and then invoke `ghc hello.hs -O2 -v3 -fforce-recomp -ddump-llvm` then at some point you'll see something like {{{ *** LLVM Optimiser: opt-3.4 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_2.ll -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -O2 '--enable-tbaa=true' *** LLVM Compiler: llc-3.4 -O2 '-relocation-model=pic' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_5.lm_s '--enable-tbaa=true' '-mattr=+sse2' *** LLVM Mangler: }}} in the output -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES
by GHC 27 Feb '16

27 Feb '16

#11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 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: -------------------------------------+------------------------------------- When running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`. To reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `make` in toplevel directory. Then run: `make test CLEANUP=1 WAY=profasm TEST="T2552 cgrun045 T5626 cgrun051 cgrun016 cgrun059 T2120 T11193 T9078 overflow3 overflow2 overflow1 T10728 T7919 T11049 T5550 conc021 SplicesUsed T5654b-O1 T5654b-O0 T2552 Rules1 T3220 T7837 ColInference3 hpc_fork ffi008 fptrfail01 TH_spliceViewPat overloadedrecfldsrun04 overloadedlabelsrun04 arr004 arr007 arr008 arr003 assert T8089 readFloat stm060 T5628 tough T7411 qq007 qq008 qq009"` (some of the above tests might be failing for other reasons, but most should be about this issue) Here is an example failure: {{{ --- ./codeGen/should_run/cgrun045.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 +++ ./codeGen/should_run/cgrun045.run.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 @@ -1,3 +1,6 @@ cgrun045: hello world! CallStack (from HasCallStack): error, called at cgrun045.hs:<line>:<column> in <package-id>:Main \ No newline at end of file +CallStack (from -prof): + Main.main (cgrun045.hs:6:1-52) + Main.CAF (<entire-module>) \ No newline at end of file *** unexpected failure for cgrun045(profasm) }}} Is this expected behavior? The double callstacks look a little weird to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linke
by GHC 27 Feb '16

27 Feb '16

#11123: Arm: checkProddableBlock: invalid fixup in runtime linke --------------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Just started getting this in the last week or two, but only just now got a chance to investigate more fully. Any use of GHCi or TH will result in an error like: {{{ ghc-stage2: internal error: checkProddableBlock: invalid fixup in runtime linker: 0x41380050 (GHC version 7.11.20151122 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} As a consequence, there are now over 500 failing tests on Arm. I thought this may have been a consequence of all the recent work on `rts/Linker.c` so I checked out git commit 20e30d5f3d932d63933 (the one just before the dreaded commit 04e8366608fee4f which seemed to kick off a bunch of heavy rework in this file) but that revision causes another, even more mysterious linking failure. From what I have seen, this only affects 32 bit Arm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11009: Errors reading stdin on Windows
by GHC 27 Feb '16

27 Feb '16

#11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I'm running GHC 7.10.2 on Windows 7 x64. Given this code that reads bytes of `stdin`: {{{#!hs import Foreign.C import Foreign import System.Posix.Internals import qualified GHC.IO.FD as FD readStdin bytes = allocaBytes bytes $ \p -> throwErrnoIfMinus1 "" $ c_safe_read (FD.fdFD FD.stdin) p (fromIntegral bytes) }}} Running {{{#!hs readStdin (32 * 1024) }}} Throws the following {{{ *** Exception: resource exhausted (Not enough space) }}} Taking less bytes, e.g. `readStdin (30 * 1024)`, runs as expected. This code is motivated by [[https://github.com/haskell/bytestring/issues/35|this]] issue in the `bytestring` library. This is essentially a minimization of the error case [[https://github.com/haskell/bytestring/issues/35#issuecomment-148954406|here]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5