August 2015 - ghc-tickets

Re: [GHC] #1776: type families : couldn't match type "Elem a" against type "Elem a"
by GHC 12 Aug '15

12 Aug '15

#1776: type families : couldn't match type "Elem a" against type "Elem a" -------------------------------------+--------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj(a)microsoft.com <unknown> Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 <g> (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. <snip/> =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law <n6> this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1776#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1176: Infinite loop when printing error message
by GHC 12 Aug '15

12 Aug '15

#1176: Infinite loop when printing error message -------------------------------------+--------------------------------- Reporter: Paul_Berry@… | Owner: thorkilnaur Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: tcfail177 Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj(a)microsoft.com <unknown> Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 <g> (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. <snip/> =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law <n6> this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1176#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #694: lawbreaker in HughesPJ
by GHC 12 Aug '15

12 Aug '15

#694: lawbreaker in HughesPJ -------------------------------------+--------------------------------- Reporter: maeder@… | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"5d57087e314bd484dbe14958f9b422be3ac6641a/ghc" 5d57087/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d57087e314bd484dbe14958f9b422be3ac6641a" Pretty: fix a broken invariant (#10735) This is a backport of a bug fix from 6cfbd0444981c074bae10a3cf72733bcb8597bef in libraries/pretty: Fix a broken invariant Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/694#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #667: Efficient Map <-> Set conversions
by GHC 12 Aug '15

12 Aug '15

#667: Efficient Map <-> Set conversions ---------------------------------+----------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature | Status: closed request | Priority: normal | Milestone: Not GHC Component: | Version: 6.4.1 libraries/base | Resolution: wontfix | Keywords: Data Map Set collections Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Test Case: N/A | ---------------------------------+----------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj(a)microsoft.com <unknown> Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 <g> (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. <snip/> =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law <n6> this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/667#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option
by GHC 11 Aug '15

11 Aug '15

#10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.10.1 Coverage | Keywords: hpc | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Please see this StackOverflow question and answer for comprehensive description. http://stackoverflow.com/questions/31937302/ghc-panic-loading-temp-shared- object-failed In short, when test coverage (via HPC) is enabled (via `cabal configure --enable-coverage`) and `cabal repl` is started for non-test build target you get a GHC panic when you try to interact with your functions via REPL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10760: Conflicting typefamily instances not reported with polykinds
by GHC 11 Aug '15

11 Aug '15

#10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC fails to report conflicting instances for a open polykinded type family when the two resulting types have different kinds. I would expect conflicts to be detected regardless of the concrete kind of the result. Minimal Example: {{{#!hs type family Bar a :: k type instance Bar Int = Int --type instance Bar Int = Bool -- Conflict detected type instance Bar Int = [] -- Conflict NOT detected }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality.
by GHC 10 Aug '15

10 Aug '15

#10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: TypeLits | Operating System: Linux GADTs | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC is creating an irrelevant reflexive type equality and then failing to deduce it. The problem seems to be related to transitivity for `GHC.TypeLits.Nat`, as the example will make clear. Example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} module TypeLitsBug where import GHC.TypeLits data T a where MkT :: T Int test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () test _ = case MkT of MkT -> () }}} Error message: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ ghc -c TypeLitsBug.hs TypeLitsBug.hs:11:9: Could not deduce ((x <=? z) ~ (x <=? z)) from the context ((x <=? y) ~ 'True, (y <=? z) ~ 'True) bound by the type signature for test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () at TypeLitsBug.hs:(11,9)-(12,25) NB: ‘<=?’ is a type function, and may not be injective }}} Notice the `x <=? z` relating `x` to `z`. I only mention `x <=? y` and `y <=? z` in the program, so it seems transitivity of `<=` is implicitly involved. Also, the problem goes away if I remove the GADT pattern match. I asked Iavor about this and he suspected the ambiguity check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error
by GHC 10 Aug '15

10 Aug '15

#10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I’m trying to build GHC HEAD, but it fails for me: {{{ ~/build/haskell/ghc $ make -j4 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/Coercion.o ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Iface Lint failure In interface for ghc-7.11:CoAxiom Unfolding of ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} <no location info>: Warning: [in an imported unfolding] Ill-kinded result in type or kind ‘ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}’ type or kind ‘ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}’ kind: ghc- prim:GHC.Prim.BOX{(w) tc 347} <no location info>: Warning: [in an imported unfolding] Bad axiom application (check_ki2 <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N ghc-prim:GHC.Prim.*{(w) tc 34d} k{tv a8xP} [tv] ghc-prim:GHC.Prim.BOX{(w) tc 347}) base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} [gid] `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc- prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N) :: (ghc- prim:GHC.Prim.Proxy#{(w) tc 38w} ghc-7.11:CoAxiom.CoAxiom{tc r6O} -> base:Data.Typeable.Internal.TypeRep{tc r9z}) ~# base:Data.Typeable.Internal.Typeable{tc 2k} ghc-7.11:CoAxiom.CoAxiom{tc r6O}) Iface expr = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:654: recipe for target 'compiler/stage1/build/Coercion.o' failed make[1]: *** [compiler/stage1/build/Coercion.o] Error 1 Makefile:103: recipe for target 'all' failed make: *** [all] Error 2 }}} Even if it turns out that this is a bug in 7.8 it would be nice to build HEAD out of the box with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10750: silly assembly for comparing Doubles
by GHC 10 Aug '15

10 Aug '15

#10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #10137, #10677 Differential Revisions: | -------------------------------------+------------------------------------- A function like `f x = if x > 0.0 then ... else ...` compiles to the assembly {{{ movsd 7(%rbx),%xmm0 xorpd %xmm1,%xmm1 ucomisd %xmm1,%xmm0 seta %al movzbl %al,%eax cmpq $1,%rax jb _c1tb }}} This `seta/movzbl/cmpq/jb` is bad, we can just generate `ja` (and 7.10 did). The cause is that the code generator produces Cmm like {{{ switch [0 .. 1] %MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64)::I64 { case 0 : goto c1tb; case 1 : goto c1tc; } }}} which turns into {{{ if (%MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64) < 1) goto c1tb; else goto c1tc; }}} and then GHC is stuck. It knows how to turn `condition >= 1` into `condition`, and it knows how to turn `condition < 1` into a negated version of `condition` when possible, but there is no negated version of `MO_F_Gt_W64` (it's not `MO_F_Le_W64` because of NaNs and signed zeros). It doesn't know how to turn a negated conditional into a conditional with the branches swapped because it doesn't look at that much at once. Presumably more fallout from #10137, and maybe can be fixed simultaneously with #10677. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10339: PatternSynonyms confuse exhaustiveness check
by GHC 10 Aug '15

10 Aug '15

#10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I just noticed some odd behaviour when (ab)using pattern synonyms in the following code (whose style I don't really endorse): {{{#!hs {-# LANGUAGE PatternSynonyms, LambdaCase #-} module PatSyn1 where import System.Directory (doesFileExist) pattern Found = True pattern NotFound = False readConfigFile :: FilePath -> IO () readConfigFile filePath = doesFileExist filePath >>= \case Found -> putStrLn =<< readFile filePath NotFound -> putStrLn "File does not exist." pattern Void = () foo :: () -> () foo Void = () }}} Results in {{{ /home/hvr/Haskell/PatSyn1.hs:(11,54)-(13,47): Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ /home/hvr/Haskell/PatSyn1.hs:19:1-13: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3