May 2017 - ghc-tickets

[GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors
by GHC 19 May '17

19 May '17

#11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: GADTs | Operating System: Linux Architecture: x86 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://www.youtube.com/watch?v=6snteFntvjM A Practical Introduction to Haskell GADTs] from LambdaConf 2015, example from attachment Hole.hs: {{{#!hs {-# LANGUAGE GADTs #-} data STy ty where SInt :: STy Int SBool :: STy Bool SMaybe :: STy a -> STy (Maybe a) zero :: STy ty -> ty zero ty = case ty of SInt -> 5 SBool -> False SMaybe a -> _ }}} When running with "GHCi, version 7.11.20151226": {{{ % ghci -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.11.20151226: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: error: • Found hole: _ :: ty Where: ‘ty’ is a rigid type variable bound by the type signature for: zero :: forall ty. STy ty -> ty at /tmp/Hole.hs:8:9 • In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } • Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) Failed, modules loaded: none. Prelude> }}} when older versions (GHCi version 7.10.2) refine the type of `_` to `Maybe a`: {{{ % ghci-7.10.2 -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: Found hole ‘_’ with type: Maybe a Where: ‘a’ is a rigid type variable bound by a pattern with constructor SMaybe :: forall a. STy a -> STy (Maybe a), in a case alternative at /tmp/Hole.hs:12:3 Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } Failed, modules loaded: none. Prelude> }}} Regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12468: GADTs don't refine hole types
by GHC 19 May '17

19 May '17

#12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apologies if this is a dupe. I did look! {{{ #!haskell {-# LANGUAGE GADTs #-} data T a where I :: T Int f :: T a -> a f I = _ }}} This gives the type error: {{{ • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the type signature for: f :: forall a. T a -> a at test.hs:6:6 • In the expression: _ In an equation for ‘f’: f I = _ • Relevant bindings include f :: T a -> a (bound at test.hs:7:1) }}} It should say something about `a` being `Int` in this branch. I'm using GHC 8.0.1 on OSX El Capitan. I think this may be a regression; I have a vague memory of it working with GHC 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13723: Recover gracefully from simplifier tick exhaustion
by GHC 19 May '17

19 May '17

#13723: Recover gracefully from simplifier tick exhaustion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't ''really'' be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are === Transformations that must be performed before `CorePrep` === I hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug. === Transformations that always reduce program size === If a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size ''immediately''. For example, {{{#!hs foldr c n (build f) ==> f c n }}} is always fine. These transformations can share a tick limit with the mandatory transformations mentioned above. === Transformations that never increase program size === We can be generous with these, but need some limit. === Transformations that may increase program size === These need the harshest limit, of course, but probably not (much?) harsher than what we currently have. ---- The idea is that even if one tick limit is exceeded, the "higher priority" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13725: Remove false dependency on the destination of the popcnt instruction
by GHC 18 May '17

18 May '17

#13725: Remove false dependency on the destination of the popcnt instruction -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3539 | Wiki Page: -------------------------------------+------------------------------------- fryguybob writes in Phab:D3539, > Some Intel processors appear to have a false dependency on the destination of the popcnt instruction. This could lead to poor performance. A simple way to prevent this is to clear the destination register immediately before the popcnt instruction. Currently I can't produce code from GHC where the source and destination registers are not the same (perhaps someone is interested in producing a test case that does). I'm putting this here in case anyone is interested in investigating further. I'm opening this ticket so I can bump the diff out of the review queue, in hopes that someone might some day pick it up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2
by GHC 18 May '17

18 May '17

#13722: intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- in a bash shell type for i in {1..10}; do make TEST=hs_try_putmvar003 WAY=threaded2 ; done if you look at the output you will probably see at least one instance of {{{ cd "./concurrent/should_run/hs_try_putmvar003.run" && ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100 Wrong exit code for hs_try_putmvar003(threaded2)(expected 0 , actual 134 ) Stderr ( hs_try_putmvar003 ): /bin/sh: line 1: 45386 Abort trap: 6 ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100 *** unexpected failure for hs_try_putmvar003(threaded2) }}} This was on a Mac running the latest OS and Xcode. I can attach the Apple problem report if that helps. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13722> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly"
by GHC 18 May '17

18 May '17

#13721: posix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly" -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1-rc2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- make TEST=posix004 {{{ results in ... cd "../../libraries/unix/tests/libposix/posix004.run" && ./posix004 SUMMARY for test run started at Thu May 18 18:21:52 2017 ADT 0:00:03 spent to go through 1 total tests, which gave rise to 10 test cases, of which 9 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures }}} but then I get an Apple problem report window that says: "posix004 quit unexpectedly" Problem details and system configuration attached. This my be Mac specifc but leaving as unknown for now until we have more details -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13720: INLINE pragma semantics changed since 8.0.2
by GHC 18 May '17

18 May '17

#13720: INLINE pragma semantics changed since 8.0.2 -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before. {{{#!hs module A where {-# INLINE f #-} f x = h x h x = x {-# RULES "h x" forall x . h x = error "REWRITE" #-} }}} {{{#!hs module B where import A qux = f 5 }}} Then running {{{ > ghc-8.0.2 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Str=DmdType x] qux = error .... }}} {{{ > ghc-8.2.0.20170507 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5 qux :: Integer [GblId, Caf=NoCafRefs, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] qux = 5 }}} Inspecting the unfoldings, we see that 8.2 optimises the unfoldings to inline `h` before the rule can apply. {{{ d61439f58ce9c5a268304423a43b9b44 f :: p -> p {- Arity: 1, HasNoCafRefs, Strictness: <S,1*U>, Inline: (sat-args=1), Unfolding: InlineRule (1, False, True) (\ @ p (x :: p) -> x) -} }}} Is this new behaviour intentional? It seems possible that it will break some programs which use rewrite rules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase
by GHC 18 May '17

18 May '17

#13717: Pattern synonym exhaustiveness checks don't play well with EmptyCase -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write {{{#!hs newtype Fin (n :: Nat) = Fin Natural -- constructor not exported pattern FZ :: () => forall m. n ~ 'S m => Fin n pattern FS :: () => n ~ 'S m => Fin m -> Fin n {-# COMPLETE FZ, FS #-} }}} I would very much like to be able to write {{{#!hs finZAbsurd :: Fin 'Z -> Void finZAbsurd x = case x of }}} but this gives me a pattern coverage warning! That's certainly not what we want. I believe what we actually want is this: When checking empty case, check that ''at least one'' complete pattern set is impossible. In this case, it would see two complete pattern sets: the built-in `{Fin}` and the user-decreed `{FZ, FS}`. Since neither `FZ` nor `FS` have matching types, we should conclude that the empty case is fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13714: Guard pages instead of Heap/Stack limit checks in Cmm
by GHC 18 May '17

18 May '17

#13714: Guard pages instead of Heap/Stack limit checks in Cmm -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Recently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm] This is not cheap and introduce more branch mispredictions and instructions. What you think if we use guard OS pages (that trigger exceptions when someone try to read/write on them) around Stack and Heap? Stack and Heap sizes should be aligned on page size (usually 4K) and with sizes that fits 4K pages. We could handle such exceptions so we could do GC if needed. This trick is usually found in some memory managers for finding out-of- bounds bugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3