From ghc-devs at haskell.org Tue Jul 1 02:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 02:06:41 -0000 Subject: [GHC] #9145: hp2ps produces odd negative sawtooth In-Reply-To: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> References: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> Message-ID: <062.6972b7a79c70bdd252c683fae2a4a76e@haskell.org> #9145: hp2ps produces odd negative sawtooth ------------------------------------------------+-------------------------- Reporter: blackdog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Reid Barton ): In [changeset:"b735883016b946372cb44b6c5d86dc36c126a8cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b735883016b946372cb44b6c5d86dc36c126a8cf" Avoid integer overflow in hp2ps (#9145) This is slightly hackish, but hp2ps is already convoluted enough that I don't feel bad about it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 02:17:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 02:17:19 -0000 Subject: [GHC] #9145: hp2ps produces odd negative sawtooth In-Reply-To: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> References: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> Message-ID: <062.c6ababa63328c1f276336699ce761478@haskell.org> #9145: hp2ps produces odd negative sawtooth ------------------------------------------------+-------------------------- Reporter: blackdog | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Here is the corrected heap profile of your RAM-guzzling program! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 02:19:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 02:19:41 -0000 Subject: [GHC] #9145: hp2ps produces odd negative sawtooth In-Reply-To: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> References: <047.03c89688f26e28e9e8632b9beeab4491@haskell.org> Message-ID: <062.e970596fac52f287629f4159e9e241a9@haskell.org> #9145: hp2ps produces odd negative sawtooth ------------------------------------------------+-------------------------- Reporter: blackdog | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by blackdog): Heh, thank you. I've since converted it to an iteratee-based approach and it's steady on 70mb, but it's good to know that hp2ps is now safe for terrible programs everywhere :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 02:41:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 02:41:52 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.a0f60f4deeffad0def9f7f9404ac6e90@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by pumpkin): Just a minor bump on this. The more fancy GADT and Poly/DataKind programming I do, the more this bothers me. It seems like a real pity to be penalized (with an extra box) for choosing to encode invariants in indices, especially with all the new delicious features GHC has been getting recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 02:45:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 02:45:46 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.4ff3b16d74194cd9e3598230920a441f@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jmcarthur): * cc: jake.mcarthur@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 03:38:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 03:38:10 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.c1a9df6c06147fe3752c732045d3c88f@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by pumpkin): To be clear about what I'm looking for: {{{ #!haskell data IntList where Nil :: IntList Cons :: Int -> IntList -> IntList data Nat = Z | S Nat data IntVec :: Nat -> * where NilV :: IntVec Z ConsV :: Int -> IntVec n -> IntVec (S n) -- N.B: not data newtype Exists (f :: k -> *) = forall x. Exists (f x) type IntVecList = Exists IntVec -- IntVec and IntVecList should be isomorphic! If Exists can't be a newtype, I have to pay a penalty for adding indices to my type :( }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 05:54:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 05:54:11 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.a7a4f6109a8015eb5f2495e5ce60f540@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): This patch fixes building HPC dynamic libraries, at least on Linux x86_64. Note that I haven't tested whether the resulting libraries are correct in any sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 05:55:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 05:55:34 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.6daf8842d92d6f4de796a78f07b68f12@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 09:54:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 09:54:08 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file Message-ID: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is essentially augustss's proposal from ticket #1409: I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 09:54:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 09:54:37 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.9d6d66e5607abdb29641412f9d522736@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by ezyang: Old description: > This is essentially augustss's proposal from ticket #1409: > > I would settle for a solution where I annotate those entities in a module > that would go in the hs-boot file. So instead of me having to go through > the trouble of creating an extra file I could just say, e.g., > > Replying to [comment:13 augustss]: > > I would settle for a solution where I annotate those entities in a > module that would go in the hs-boot file. So instead of me having to go > through the trouble of creating an extra file I could just say, e.g., > > > > {{{ > > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > > data T = ... > > foo :: ... > > foo = ... > > }}} > > > > The values that have an annotation would have to have a type signature. > > This should be eminently doable. Here is a more fleshed out proposal. > > First, consider the definition of an hs-boot file in the absence of > mutual recursion (i.e. no breakers are necessary). In this case, the hi- > boot file for an hs file is precisely the hi file produced after ordinary > renaming and typechecking of the module. > > As an optimization, we would like to avoid typechecking definitions if an > explicit type signature is present (if the type signature is absent, we > have no choice.) There are a few choices here: we can force users to give > top-level declarations for all exported functions (so unconditionally > error if something is missing, by filtering out the relevant value > declarations from the source), or we can go ahead and do full > typechecking when the signature is missing. (The former is probably the > simplest.) > > Now, how to handle breakers? We need to avoid typechecking them, since > their recursive dependence means that they would not type check properly. > So we should also filter out their type signatures. (Furthermore, if we > are inferring some signatures, we need to make sure that their > definitions don't rely on any breakers. For this reason, it is probably > simplest to just require explicit type signatures.) > > If the mechanism for specifying breakers is exclusionary (as opposed to > an inclusionary method of saying what values are in the signature), there > is an awkward problem of syntax for exporting only an abstract type: the > logical choices mean the wrong thing (`T(..)` seem to imply the type is > eliminated entirely, whereas `T` seems to imply that the type should be > eliminated, but not eh constructors.) > > Summary: > > 1. Require top-level signatures in hs to hs-boot files(?) > 2. Exclusionary or inclusionary signature pragma? > 3. Filter out value declarations and excluded files, then > rename/typecheck as normal, producing hi-boot file New description: This is essentially augustss's proposal from ticket #1409: Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 10:07:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 10:07:57 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.0fcd1a78bef8a51d98ff8186f291dd6d@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by ezyang: Old description: > This is essentially augustss's proposal from ticket #1409: > > Replying to [comment:13 augustss]: > > I would settle for a solution where I annotate those entities in a > module that would go in the hs-boot file. So instead of me having to go > through the trouble of creating an extra file I could just say, e.g., > > > > {{{ > > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > > data T = ... > > foo :: ... > > foo = ... > > }}} > > > > The values that have an annotation would have to have a type signature. > > This should be eminently doable. Here is a more fleshed out proposal. > > First, consider the definition of an hs-boot file in the absence of > mutual recursion (i.e. no breakers are necessary). In this case, the hi- > boot file for an hs file is precisely the hi file produced after ordinary > renaming and typechecking of the module. > > As an optimization, we would like to avoid typechecking definitions if an > explicit type signature is present (if the type signature is absent, we > have no choice.) There are a few choices here: we can force users to give > top-level declarations for all exported functions (so unconditionally > error if something is missing, by filtering out the relevant value > declarations from the source), or we can go ahead and do full > typechecking when the signature is missing. (The former is probably the > simplest.) > > Now, how to handle breakers? We need to avoid typechecking them, since > their recursive dependence means that they would not type check properly. > So we should also filter out their type signatures. (Furthermore, if we > are inferring some signatures, we need to make sure that their > definitions don't rely on any breakers. For this reason, it is probably > simplest to just require explicit type signatures.) > > If the mechanism for specifying breakers is exclusionary (as opposed to > an inclusionary method of saying what values are in the signature), there > is an awkward problem of syntax for exporting only an abstract type: the > logical choices mean the wrong thing (`T(..)` seem to imply the type is > eliminated entirely, whereas `T` seems to imply that the type should be > eliminated, but not eh constructors.) > > Summary: > > 1. Require top-level signatures in hs to hs-boot files(?) > 2. Exclusionary or inclusionary signature pragma? > 3. Filter out value declarations and excluded files, then > rename/typecheck as normal, producing hi-boot file New description: This is essentially augustss's proposal from ticket #1409: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 11:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 11:19:40 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.1c9dfe61af8d6c2a9c52b1b970dce3a8@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by arotenberg): Having now read "A transformation based optimiser for Haskell", I learned about the `let-no-escape` optimization, which I was not previously aware of. Looking at the output of `-ddump-stg` on UglyBranching, all of the local lambdas are actually bound by `let-no-escape`, which makes the whole question irrelevant. Well, now I feel silly. I guess if there's something to be learned here, it's that `let-no-escape` could be publicized better! Everything I've seen on the internet up until now was all "look at the Core, if you see `let`, that's a Bad Thing and you might want to Do Something About It!" (Quoth the GHC docs: "If profiling has pointed the finger at particular functions, look at their Core code. lets are bad, cases are good, ... nested lambdas are bad, ...") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 11:29:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 11:29:38 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.8644736731c1576a2f1aa6dd591983c3@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): Replying to [comment:17 ross]: > Here's a different suggestion for rebinding that is perhaps more analogous to the expression case. We could consider do and if commands as sugar for more primitive commands: > {{{ > do { rec { ss }; ss' } = > do { vs <- (| fixA (\ ~vs -> do { ss; returnA -< vs })|); ss' } > }}} Can the desugaring of `rec` be viewed as: > {{{ > do { rec { ss }; ss' } = > (| fixA (\ ~vs -> do { ss; returnA -< vs })|) `bind` \ vs -> ss' } > }}} ? I'm working on this new desugaring now, but I'm unable to give any estimates of how long it might take. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 11:51:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 11:51:31 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.7d68e91a638868d633c8d0e423269d0b@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Don't let this hold you up, but I can't really understand the proposal above. Where is augustss's proposal in #1409? There's ''lots'' of text there. What is a "mutual recursion breaker"? Is it something that ''does'' appear in the hi-boot file? Or is it something that ''does not'' appear in the hi-boot file? (Sounds like the latter.) Are you proposing that every module, even in the absence of pragmas, now produce both a hi and a hi-boot file? Your proposal suggests that every top-level definition will now need a type signature, but I don't imagine you mean that. Is this only when some pragma is specified? Then, not quite understanding what breakers are, my understanding goes downhill from there. In your summary, is there something that distinguishes a "hs to hs-boot file" from a normal hs file? Sorry -- this is interesting to me, but I'm a little lost here. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 12:08:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 12:08:14 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.2e16b805fc96418a3b05b6b2b032dbe5@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Replying to [comment:3 goldfire]: > Where is augustss's proposal in #1409? There's ''lots'' of text there. I quoted his comment, but it's this one: https://ghc.haskell.org/trac/ghc/ticket/1409#comment:13 > What is a "mutual recursion breaker"? Is it something that ''does'' appear in the hi-boot file? Or is it something that ''does not'' appear in the hi-boot file? (Sounds like the latter.) Yep, the latter. > Are you proposing that every module, even in the absence of pragmas, now produce both a hi and a hi-boot file? Hm, that's probably bad. It should only generate an hi-boot file if there is some pragma. > Your proposal suggests that every top-level definition will now need a type signature, but I don't imagine you mean that. Is this only when some pragma is specified? Yep. > Then, not quite understanding what breakers are, my understanding goes downhill from there. > > In your summary, is there something that distinguishes a "hs to hs-boot file" from a normal hs file? > > Sorry -- this is interesting to me, but I'm a little lost here. Thanks! So let's be a bit more concrete about the use case. 1. You're writing a pair of modules A and B, and you realize that you want some mutual recursion. 2. In the old world order, you'd pick one module to be loop-breaker (say A), create a boot file (A.hs-boot), and modify B's import to be a SOURCE import. 3. In the new world order, you instead add a pragma to A.hs which specifies which identifies would have been placed in the A.hs-boot file. B still receives a SOURCE import as before. 4. Now, when performing `--make` compilation, we notice that A.hs has a pragma, so we pretend as if an hs-boot file existed, and first compile A.hs as a boot file, then compiling B.hs and then A.hs normally. I haven't worked out how to adjust one-shot compilation to work with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 12:11:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 12:11:25 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.9630ddc9cfd43fad5d37e73909b343a2@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by simonpj): Yes, let-no-escape should be better documented. And I feel bad that although it's terribly important for performance, it's entirely implicit in Core, and it's not hard for a transformation to inadvertently lose the LNE property. I'd like it to be more explicit, somehow. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 13:11:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 13:11:16 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.26262009a02e20b7926c22aabf2c2df9@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): I don't understand how one is supposed to actually use these HPC libraries as the `.mix` files don't seem to be installed anywhere by cabal. What are the people who encounter this issue actually trying to do? I did manage to do some manual tests and noticed a difference in behavior between the static and dynamic libraries: there are more packages included in the `.tix` file with the dynamic libraries. I don't understand why or know whether this is a good thing or a bad thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 13:20:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 13:20:35 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.5719884e3624628ceed26eba2a3fc821@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): rwbarton: first off, thanks for working on this! To answer your question, the typical workflow is to build the package in hpc mode (`cabal install -j --enable-library-coverage myprogram`), then run `cabal test`. It should then run the tests and generate an hpc report somewhere under `dist/` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 13:26:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 13:26:06 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.abc53fb6d4deedf09024e7965152069c@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * priority: normal => high Comment: Edward says he'll look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 13:37:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 13:37:13 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.5fbc7f1509260bfdd4d31f3e74a6b967@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ezyang): Since we dropped the ball on this and 7.8.3 is really soon, the current proposal is to just revert to the original numbering, but not add the big switch statement. This should be a small noncontroversial patch, and then we can fix it properly later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 13:37:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 13:37:32 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.c931b70de58cf6fd86482ca5afe5cf78@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ezyang): * owner: simonmar => ezyang * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:11:43 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.1836e6ede767bf85ea213f62cffffa06@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): I can't seem to get `cabal test` to work on any package. Could you give exact instructions for building and testing (with HPC) any package of your choice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:13:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:13:50 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.7532fca689e3cd909b8866d9510abcac@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5f3c5384df59717ca8013c5df8d1f65692867825/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5f3c5384df59717ca8013c5df8d1f65692867825" Partially fix #9003 by reverting bad numbering. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:14:46 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.83f03cb658397799a94906b835fb21f7@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ezyang): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:20:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:20:38 -0000 Subject: [GHC] #9172: integer overflow in allocate() In-Reply-To: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> References: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> Message-ID: <062.fd0ac1b9984fe7985e343ab6bdb9e4c6@haskell.org> #9172: integer overflow in allocate() -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Reid Barton ): In [changeset:"db64180896b395283f443d66a308048c605b217d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="db64180896b395283f443d66a308048c605b217d" Check for integer overflow in allocate() (#9172) Summary: Check for integer overflow in allocate() (#9172) Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D36 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:24:01 -0000 Subject: [GHC] #9254: Entered absent argument (again) In-Reply-To: <046.8007e83c84e154810aac28174a2424bb@haskell.org> References: <046.8007e83c84e154810aac28174a2424bb@haskell.org> Message-ID: <061.8c2e12787bfe4cd636986c20d14a9c5f@haskell.org> #9254: Entered absent argument (again) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"d6ee82b29598dcc1028773dd987b7a2fb17519b7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d6ee82b29598dcc1028773dd987b7a2fb17519b7" Fix demand analyser for unboxed types This is a tricky case exposed by Trac #9254. I'm surprised it hasn't shown up before, because it's happens when you use unsafePerformIO in the right way. Anyway, fixed now. See Note [Analysing with absent demand] in Demand.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:24:01 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.96ff287ee7a5fb3f668a2d1a3bf4cc7d@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T9222 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"127c45ea30eaee6b5244b3f30aaa701d0ad327ac/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="127c45ea30eaee6b5244b3f30aaa701d0ad327ac" Test Trac #9222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:25:47 -0000 Subject: [GHC] #9254: Entered absent argument (again) In-Reply-To: <046.8007e83c84e154810aac28174a2424bb@haskell.org> References: <046.8007e83c84e154810aac28174a2424bb@haskell.org> Message-ID: <061.c72410b8de484816e75bc03dab0d997b@haskell.org> #9254: Entered absent argument (again) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => merge Comment: Merge to 7.8; either 7.8.3 if time or 7.8.4 if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 14:27:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 14:27:31 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.c3e11e31855f0b9ce4be670ffbd692ed@haskell.org> #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) ---------------------------------------------+----------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Test Case: stranal/should_run/T8425 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------------+----------------------------- Comment (by simonpj): jloos, thanks for highlighting that vector-binary-instances bug. For some reason, no one actually filed it as a GHC ticket so I had no idea of its existence. It turns out to be an long-standing but otherwise undetected bug. Now dignified as #9254 and fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 15:00:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 15:00:15 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.5cd23b7e534b2f78ce8cff4ec894761d@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Try `regex-applicative`. E.g.: `cabal install --enable-library-coverage --run-tests regex-applicative`. (Assuming you have cabal-install 1.20.) That should build the package, run the tests, and generate the hpc report. Obviously I can't test these instructions because of the very bug we're discussing... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 15:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 15:04:23 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.71c358bc2f94d3d4e6f95db27f98fff2@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Alternative instructions: {{{ cabal get regex-applicative cd regex-applicative* cabal install --enable-library-coverage --only-dependencies --enable-tests cabal test }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 15:05:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 15:05:56 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.006d3bf38834274db86c51bcee028dd1@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by MtnViewMark): As mentioned on phabricator, I've tested the patch and it works. This enables the Mac build to have a single build, which can be re-configured for the target machine after it has been copied onto the target machine. This is important as otherwise the HP would have to be distributed either in two forms (one for clang, one for non-clang), or with the ghc-clang- wrapper hack, which works but is brittle. Assuming this goes in, the next HP will have a script, activate-hs, which will allow the user to switch between installactions of the HP, and will also fix up these settings in cases where the users tool chain has switched from non-clang to clang. (This can happen on systems where the user has been using an old Xcode and then updates Xcode.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 15:30:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 15:30:43 -0000 Subject: [GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install Message-ID: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> #9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: clang | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Installing GHC Difficulty: Moderate (less | failed than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- 1) build GHC is built on a machine with clang -- project.mk ends up with the macro CC_CLANG_BACKEND=1 2) make binary-dist on that machine 3) bring that bindist to a machine that doesn't use clang 4) unpack the bindist, ./configure, make install This error ensues: cc1: error: unrecognized command line option "-Wno-invalid-pp-token" cc1: error: unrecognized command line option "-Wno-unicode" The problem rests in that there is on gcc invocation during that make install: /usr/bin/gcc -E ... rts/package.conf.in -o rts/dist/package.conf.install.raw This call is picking up arguments from RAWCPP_FLAGS, set in mk/config.mk, based on CC_CLANG_BACKEND, set in mk/project.mk... which was computed at build time. carter has hypothesized that adding the macro FP_CC_LLVM_BACKEND to distrib/configure.ac.in might fix this. In theory that will cause the config file that is bunded into the bindist to recompute the CC_CLANG_BACKEND flag at dist config time. However, this may not work because the only file that emits CC_CLANG_BACKEND is project.mk and that doesn't seem to get re-written during dist time config. -- so something else will be needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 16:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 16:42:13 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.1672ac3ce0c9dc5031746afa395c67cf@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: stranal/should_compile/T9208 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Probably. Feel free to have a go. It's so much a corner case that I can't bear to spend the time to think about it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 16:43:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 16:43:52 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.9e7a777219fad2c54ce87805d1b800de@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:12 Feuerbach]: > Try `regex-applicative`. E.g.: `cabal install --enable-library-coverage --run-tests regex-applicative`. (Assuming you have cabal-install 1.20.) That should build the package, run the tests, and generate the hpc report. > > Obviously I can't test these instructions because of the very bug we're discussing... Great, thanks. I did this: {{{ cabal install --only-dep --run-tests -w $HOME/ghc/inplace/bin/ghc-stage2 regex-applicative cabal get regex-applicative cd regex-applicative* cabal configure --enable-library-coverage --enable-tests -w $HOME/ghc/inplace/bin/ghc-stage2 --ghc-option=-XFlexibleContexts # see #8883 cabal test }}} and it seems to have worked fine: {{{ [... building ...] Running 1 test suites... Test suite test-regex-applicative: RUNNING... Test suite test-regex-applicative: PASS Test suite logged to: dist/test/regex-applicative-0.3.0.2-test-regex-applicative.log Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.StateQueue.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Compile.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Types.hs.html Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.Interface.hs.html Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.Reference.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Object.hs.html Writing: hpc_index.html Writing: hpc_index_fun.html Writing: hpc_index_alt.html Writing: hpc_index_exp.html Test coverage report written to dist/hpc/html/test-regex-applicative/hpc_index.html 1 of 1 test suites (1 of 1 test cases) passed. Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.StateQueue.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Compile.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Types.hs.html Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.Interface.hs.html Writing: regex- applicative-0.3.0.2/Text.Regex.Applicative.Reference.hs.html Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Object.hs.html Writing: hpc_index.html Writing: hpc_index_fun.html Writing: hpc_index_alt.html Writing: hpc_index_exp.html Package coverage report written to dist/hpc/html/regex-applicative-0.3.0.2/hpc_index.html }}} The report looks fine, too. (I tried the your first set of instructions first, and I got the same successful messages, but as far as I can tell Cabal didn't save the coverage report anywhere!) However, if I also install the dependencies (test frameworks) with `--enable-library-coverage`, then things break: {{{ [...] Running 1 test suites... Test suite test-regex-applicative: RUNNING... Test suite test-regex-applicative: PASS Test suite logged to: dist/test/regex-applicative-0.3.0.2-test-regex-applicative.log hpc: can not find HUnit-1.2.5.2/Test.HUnit.Lang in ["./.hpc","./dist/hpc/mix/regex-applicative-0.3.0.2","./dist/hpc/mix/test- regex-applicative"] }}} The test executable is not using shared libraries at all, though, so I suspect this case has always been broken. If I make the test executable dynamic, with the first set of steps, I get a report that includes two additional modules, `Text.Regex.Applicative` and `Text.Regex.Applicative.Common`, which have no coverage. I suspect this is due to static linking not linking those object files since they're not needed, while dynamic linking is monolithic. I also get a slightly different error with the second set of steps, possibly due to the same cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 16:49:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 16:49:06 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.ea8f988fad3d9e7f8e5ed29cb0169aec@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): This is the new patch that I'm using. My conclusion is that, at least on Linux x86_64, HPC now seems to work as well as it did before. I haven't actually tried with an older compiler though: what version is known to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 17:31:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 17:31:40 -0000 Subject: [GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU In-Reply-To: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> References: <047.4e8e56fbd7ab758cd0cf0b782b39823c@haskell.org> Message-ID: <062.f451e04ef127b7c99e6f4cf16d87bba5@haskell.org> #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU -------------------------------------+------------------------------------ Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Debugging this will require a fair bit of knowledge of GHC internals, so if you want to tackle it yourself then head over to Commentary/Rts and Debugging/CompiledCode. If you can find a smaller test case that demonstrates the problem and you can distribute, please add it here and I'll take a look. I'm wondering whether this is the same thing as #7320. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 18:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 18:00:43 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.da35a60dda48f2b3dd2c5833346518a3@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): It's complicated. Older version of hpc-the-executable didn't use to play well with cabal. OTOH, I thought I had used HPC successfully with 7.6.3, so I was surprised when I got this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 18:19:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 18:19:25 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.df81584338928db22b6465e20331c45a@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"e7b9c4125321308a7f71cacf4c24b7d40261ccfd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7b9c4125321308a7f71cacf4c24b7d40261ccfd" Fixup nullary typeclasses (Trac #8993) Summary: Fix test broken after Trac #8993 Test Plan: validate Reviewers: austin, simonpj, hvr Reviewed By: austin, hvr Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D34 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 18:25:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 18:25:49 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.fee8f145844e8f44a4ba8a83ee7181d4@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 19:51:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 19:51:52 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.ffdc6f10d9cd73b80c698c1dc6174fc2@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Thanks. Let me try to spit back what you're saying: {{{ module A where import B data Arf = MkArf (Maybe Bar) }}} {{{ module B where import A data Bar = MkBar (Maybe Arf) }}} The above modules will currently fail to compile because of the import cycle. The current solution is to write an ''A.hs-boot'' file declaring `data Arf` and putting a `{-# SOURCE #-}` pragma in `B`. Your proposed solution is like this: {{{ module A where {-# BOOT_TYPES Arf #-} import B data Arf = MkArf (Maybe Bar) }}} {{{ module B where import {-# SOURCE #-} A data Bar = MkBar (Maybe Arf) }}} Is this correct? I like the idea in general, but there are some pitfalls I see: * An hs-boot file tends to have a mix of `{-# SOURCE #-}` imports and regular imports. The list of imports in the hs-boot file will be different than the list in the master file, and where the `{-# SOURCE #-}` pragma appears will be different. (There's a subset relationship between the import lists, of course.) How will this new syntax figure out which imports are necessary to type check the `BOOT_TYPES`? * It is sometimes desirable to include type ''definitions'' in hi-boot files. How does this syntax accommodate that need? * Similarly, one may want type synonyms and type families available in hi- boot files. How do these work? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 1 19:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jul 2014 19:59:34 -0000 Subject: [GHC] #9172: integer overflow in allocate() In-Reply-To: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> References: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> Message-ID: <062.1b406f3000d57855d0cb286de6e81491@haskell.org> #9172: integer overflow in allocate() -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Runtime System | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => merge * milestone: => 7.8.4 Comment: No rush on merging this because there are a fair number of similar issues that I intend to also fix at some point. In fact I would be totally fine with leaving it out of 7.8 completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 06:49:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 06:49:56 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.427c9f6b1441924d2130de8ac513a0da@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Replying to [comment:13 pumpkin]: > To be clear about what I'm looking for: > Yes, I always wondered how existentially quantifying over a type constructor with non-* domain kinds can ever necessitate extra information at runtime. I fully support the reopen proposal because of `data Hidden :: k -> * where Hide :: t a -> Hidden t` wants to be a `newtype`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 08:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 08:06:41 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.76a8e09b13d752e989a9c26c0461e487@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:39 jstolarek]: > Replying to [comment:17 ross]: > > Here's a different suggestion for rebinding that is perhaps more analogous to the expression case. We could consider do and if commands as sugar for more primitive commands: > > {{{ > > do { rec { ss }; ss' } = > > do { vs <- (| fixA (\ ~vs -> do { ss; returnA -< vs })|); ss' } > > }}} > > Can the desugaring of `rec` be viewed as: > > {{{ > do { rec { ss }; ss' } = > (| fixA (\ ~vs -> do { ss; returnA -< vs })|) `bind` \ vs -> do { ss' } > }}} > > ? Yes, that's a combination of the above and the rule for `<-`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 12:27:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 12:27:03 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.cb2462c7de54e395106c0508e990f502@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): Simon, I think I need some help with typechecking. I defined `thenA` (Ross' `bind_`) to have the type `Arrow a => a (e,s) b -> a (e,s) c -> a (e,s) c`. Now I'm trying to typecheck `thenA` operator stored inside `BodyStmtA` constructor (a new arrow equivalent of monadic `BodyStmt`). I wrote something like this: {{{ tcArrDoStmt env _ (BodyStmtA rhs then_op _) res_ty thing_inside = do { (rhs', elt_ty) <- tc_arr_rhs env rhs ; thing <- thing_inside res_ty ; s <- newFlexiTyVarTy liftedTypeKind ; b <- newFlexiTyVarTy liftedTypeKind ; c <- newFlexiTyVarTy liftedTypeKind ; then_op' <- tcSyntaxOp DoOrigin then_op (mkFunTys [ mkCmdArrTy env (mkBoxedTupleTy [elt_ty, s]) b , mkCmdArrTy env (mkBoxedTupleTy [elt_ty, s]) c] (mkCmdArrTy env (mkBoxedTupleTy [elt_ty, s]) c)) ; return (BodyStmtA rhs' then_op' elt_ty, thing) } }}} The test function I'm compiling looks like this: {{{ test :: Arrow a => a i i test = proc n -> do (arr id) -< n returnA -< n }}} Using `-dcore-lint` during complation reveals offences similar to the ones I experienced earlier: {{{ Argument value doesn't match argument type: Fun type: a_auK (i_auL, GHC.Prim.Any) GHC.Prim.Any -> a_auK (i_auL, GHC.Prim.Any) GHC.Prim.Any -> a_auK (i_auL, GHC.Prim.Any) GHC.Prim.Any Arg type: a_auK (i_auL, ()) i_auL Arg: ds_dvR @ (i_auL, ()) @ i_auL @ i_auL (ds_dvQ @ (i_auL, ()) @ i_auL (\ (ds_dw0 :: (i_auL, ())) -> case ds_dw0 of _ [Occ=Dead] { (ds_dvZ, _ [Occ=Dead]) -> ds_dvZ })) (Control.Arrow.arr @ a_auK $dArrow_auX @ i_auL @ i_auL (T7828.id @ i_auL)) }}} I tried to write the typechecking of `thenA` to match the actual type, just like you wrote in [ticket:7828#comment:29]. But I don't see how could I replace my new type variables `s`, `b` and `c` with something concrete. I believe that `s` should be allowed to be anything (polymorphism in the environment), so I don't know what could it be other than a new tyvar. Tracing the calls lead me to believe that `res_ty` is the type of the whole `do` expression, so I don't think it has anything to do with the type of `thenA`. Can I ask for your guidance here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 12:38:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 12:38:58 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.6453e62de53603ed9422d73943b21342@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jberthold): I would prefer if the patch included a change to some event (eventlog header), so that the 7.8.2 version can be recognized by reading the header. This is the best way to fix ghc-events. The event EVENT_USER_MARKER was new in 7.8, and my fix to ghc-events- parallel was based on this. If the old numbering is restored now, I would like to have a way to distinguish version 7.8.3 from 7.8.2, which is easily done by changing events (could be adding an event which is not used, or extending an event with a new field). If any such change is pending, I suggest to apply it now, or revert the numbering later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 14:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 14:46:33 -0000 Subject: [GHC] #9258: Type inference fails with closed type families Message-ID: <047.f789d04cbe11697dc307238982aa620c@haskell.org> #9258: Type inference fails with closed type families ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Consider the following module: {{{ {-# LANGUAGE TypeFamilies #-} module M where type family D d a where D () a = Bool data Descr d = Descr { fld :: D d Double } --descrIn :: (D d Double ~ Bool) => Descr d descrIn = Descr { fld = True } }}} I expected ghc to infer the commented out type signature, but instead I get an error: {{{ $ ghc -Wall -c ./test/M.hs test\M.hs:12:25: Couldn't match expected type `D d0 Double' with actual type `Bool' The type variable `d0' is ambiguous Relevant bindings include descrIn :: Descr d0 (bound at test\M.hs:12:1) In the `fld' field of a record In the expression: Descr {fld = True} }}} Uncommenting the type signature makes the module compile. As an aside, the signature I really want ghc to deduce is {{{ descrIn :: Descr () }}} But since ghc doesn't (yet) use the full information provided by the closed type family equations this doesn't happen. Still, it should be able to figure out the commented out one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:12:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:12:01 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.fae071b871f0ae06b6aab56728122411@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"34f7e9a3c99850859901ca74370f55f1d4e2279a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="34f7e9a3c99850859901ca74370f55f1d4e2279a" Control CPP through settings file (#8683) Summary: Allow the CPP program and flag choices for GHC be configured via the the ghc settings file Test Plan: ran validate yesterday Reviewers: hvr, austin, mzero, simonmar Reviewed By: austin, mzero, simonmar Subscribers: mzero, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D26 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:12:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:12:01 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.6413c5566afd1e6e1e8a2aac2f7ccf66@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar --------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b0316cdb10fbd9eaca7ede28c7bb3eb19f7766bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b0316cdb10fbd9eaca7ede28c7bb3eb19f7766bf" reading/writing blocking FDs over FD_SETSIZE is broken (Partially Trac #9169) Summary: libraries/base/cbits/inputReady.c had no limits on file descriptors. Add a limit as non-threaded RTS does. Signed-off-by: Sergei Trofimovich Test Plan: none Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D28 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:12:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:12:01 -0000 Subject: [GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling In-Reply-To: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> References: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> Message-ID: <060.b23d35fa74b7520629ea3fad31dd3799@haskell.org> #8787: compiler/ghc.mk: restore GhcHcOpts variable handling -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"423caa85db277a63df8c2aa071cada82d2181b6e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="423caa85db277a63df8c2aa071cada82d2181b6e" compiler/ghc.mk: restore GhcHcOpts variable handling (Trac #8787) Summary: wiki and mk/config.mk.in suggests setting GhcHcOpts for compiler-wide haskell flags. But it does not work for a while now (broke around ca07d92837fc1e3ae9be67bb7d9e7f1b8035b00f) Signed-off-by: Sergei Trofimovich Test Plan: 'make' shows now ghc timing as it used to be Reviewers: simonmar, austin Reviewed By: austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D29 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:12:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:12:02 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' In-Reply-To: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> References: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> Message-ID: <060.86ff18eaf26e2d9cce55b98749b09d83@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"34bae1f737e1492c152ccaafd457697b621c606b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="34bae1f737e1492c152ccaafd457697b621c606b" includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' (Trac #8789) Summary: git history does not contain state where 'WITHSMP' macro was ever defined. It should have always been '!NOSMP'. Signed-off-by: Sergei Trofimovich Test Plan: build tested Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D33 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:13:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:13:09 -0000 Subject: [GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling In-Reply-To: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> References: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> Message-ID: <060.d80fea7cd432d328f71edefd309acef6@haskell.org> #8787: compiler/ghc.mk: restore GhcHcOpts variable handling -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:14:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:14:35 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.a10b5e7f988e32722588c3e2ba526800@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar --------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => patch Comment: Sorry, this commit had the wrong trac number, it seems! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:14:46 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' In-Reply-To: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> References: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> Message-ID: <060.c42bc7fd1ca1dd0d195daf5be0de8979@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 15:15:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 15:15:16 -0000 Subject: [GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar In-Reply-To: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> References: <049.23b37a7a3374245a7e82fd5db3c1a49c@haskell.org> Message-ID: <064.d062b9bd40735c929aa9cc6aa3ddecde@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar --------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:12:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:12:39 -0000 Subject: [GHC] #9085: Inaccessible equations in a closed type family should be a warning, not an error In-Reply-To: <047.6f253560297252689a57f29dc4617e22@haskell.org> References: <047.6f253560297252689a57f29dc4617e22@haskell.org> Message-ID: <062.94b81f4c59d9fc09dc188d63f0177c9f@haskell.org> #9085: Inaccessible equations in a closed type family should be a warning, not an error -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.3 Operating System: Unknown/Multiple | Version: 7.8.2 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_compile/T9085 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:12:51 -0000 Subject: [GHC] #9172: integer overflow in allocate() In-Reply-To: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> References: <047.b4f6b9adf9374ef0bf3fb465ecef5eea@haskell.org> Message-ID: <062.14504b2747cbaf151e73e1c998b17ffc@haskell.org> #9172: integer overflow in allocate() -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:12:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:12:57 -0000 Subject: [GHC] #9222: Unexpected DataKind Panic In-Reply-To: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> References: <045.cffc02ed4ea68b3271b743a554574855@haskell.org> Message-ID: <060.75dacc76b443fac822303af77c74de45@haskell.org> #9222: Unexpected DataKind Panic --------------------------------------------+------------------------------ Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T9222 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:13:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:13:10 -0000 Subject: [GHC] #9254: Entered absent argument (again) In-Reply-To: <046.8007e83c84e154810aac28174a2424bb@haskell.org> References: <046.8007e83c84e154810aac28174a2424bb@haskell.org> Message-ID: <061.8c48f7c83268d0cdcd2fbd81eaae8fd2@haskell.org> #9254: Entered absent argument (again) -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:13:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:13:38 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.cb76cb33aa4ad0e4cfc2ea3a82adb000@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:16:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:16:58 -0000 Subject: [GHC] #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) In-Reply-To: <044.558797842cec9427e028f9e25a777548@haskell.org> References: <044.558797842cec9427e028f9e25a777548@haskell.org> Message-ID: <059.ef30ff32709d69f85213d0f651b75d79@haskell.org> #9208: panic - attempt to prod-split strictness call demand C(S(C(C(S(LS))))) -------------------------------------------------+------------------------- Reporter: luite | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: stranal/should_compile/T9208 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: OK, merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 16:48:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 16:48:44 -0000 Subject: [GHC] #9258: Type inference fails with closed type families In-Reply-To: <047.f789d04cbe11697dc307238982aa620c@haskell.org> References: <047.f789d04cbe11697dc307238982aa620c@haskell.org> Message-ID: <062.ae3697a26a668528ef85c981d21ece35@haskell.org> #9258: Type inference fails with closed type families -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): I'm not an expert here, but it looks like you expect GHC to infer the arguments of s type family based on its result. I believe that's not possible in general and my guess is that GHC doesn't even try, even for a trivial case such as yours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:01:07 -0000 Subject: [GHC] #9258: Type inference fails with closed type families In-Reply-To: <047.f789d04cbe11697dc307238982aa620c@haskell.org> References: <047.f789d04cbe11697dc307238982aa620c@haskell.org> Message-ID: <062.8e3c7791e998202e15491745dcb50741@haskell.org> #9258: Type inference fails with closed type families -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by augustss): I don't see why ghc couldn't infer the commented out type. In a similar example {{{ --f :: D d Double ~ Double => Descr d -> Double f d = fld d :: Double }}} ghc is able to infer the commented out type. (Of course, for this function an error message would have been appropriate since there is no way this function can ever be used; it's like having Bool~Double as a constraint.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:01:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:01:55 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.9b681201f5b5475271c25e4066e0a0e9@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:16 Feuerbach]: > OTOH, I thought I had used HPC successfully with 7.6.3, so I was surprised when I got this error. Is it possible that you just weren't building dynamic libraries then, only static libraries, as it was the default for Cabal at the time? After all, the test executable is linked statically by default anyways so for the purpose of testing building the dynamic libraries is just unnecessary extra work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:11:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:11:10 -0000 Subject: [GHC] #9258: Type inference fails with closed type families In-Reply-To: <047.f789d04cbe11697dc307238982aa620c@haskell.org> References: <047.f789d04cbe11697dc307238982aa620c@haskell.org> Message-ID: <062.ae9ee8db71cb690937d121530f87b34f@haskell.org> #9258: Type inference fails with closed type families -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by josef): It's the monomorphism restriction kicking in. The module compiles just fine with `-XNoMonomorphismRestriction` and infers the expected type to `decrIn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:14:33 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.be0669ab0279e47e56d641d1f39587f4@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): Replying to [comment:17 rwbarton]: Yes, that was indeed the case. I specifically had `shared: False` in `cabal.config` until 7.8 came out. Thus HPC probably never worked with dynamic libraries, but it wasn't noticed until recently, when dynamic libraries became necessary and widely used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:20:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:20:08 -0000 Subject: [GHC] #9258: Type inference fails with closed type families In-Reply-To: <047.f789d04cbe11697dc307238982aa620c@haskell.org> References: <047.f789d04cbe11697dc307238982aa620c@haskell.org> Message-ID: <062.b9dcc58b66346f9f42d99d79702a4508@haskell.org> #9258: Type inference fails with closed type families -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by augustss): Argh! You'd think I'd be old enough to turn off the monomorphism restriction. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:20:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:20:48 -0000 Subject: [GHC] #9258: Type inference fails with closed type families In-Reply-To: <047.f789d04cbe11697dc307238982aa620c@haskell.org> References: <047.f789d04cbe11697dc307238982aa620c@haskell.org> Message-ID: <062.3bbdc8323226862b7fab22e8b5eaef95@haskell.org> #9258: Type inference fails with closed type families -------------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by augustss): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:39:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:39:33 -0000 Subject: [GHC] #9102: Assertion failure in CoreUtils.lhs In-Reply-To: <048.72681b4014e365b606ae951bed049559@haskell.org> References: <048.72681b4014e365b606ae951bed049559@haskell.org> Message-ID: <063.2e851cd73cbcddc694a6a0b7c90eb4a6@haskell.org> #9102: Assertion failure in CoreUtils.lhs -------------------------------------+------------------------------------ Reporter: tmcdonell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:42:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:42:57 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.b891480904986719c12a2e419dda2f0f@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Reid Barton ): In [changeset:"3285a3d5bc7419464f5d2e6cef7c3adb9bca65c3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3285a3d5bc7419464f5d2e6cef7c3adb9bca65c3" Mark HPC ticks labels as dynamic This enables GHC's PIC machinery for accessing tickboxes of other packages correctly when building dynamic libraries. Previously GHC was doing strange and wrong things in that situation. See #9012. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 17:43:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 17:43:35 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.f5a871b81795385e8c19d08f5bcfffc4@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: patch => merge Comment: Thanks. Then I understand what is going on on the GHC side enough to be confident that this patch is correct, or at least strictly more correct than the original. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:05:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:05:33 -0000 Subject: [GHC] #5280: System.Random commits (rand `mod` base) error. In-Reply-To: <047.60f391d6681d1ce2e4d33e581c53c327@haskell.org> References: <047.60f391d6681d1ce2e4d33e581c53c327@haskell.org> Message-ID: <062.8c5e173bedc03e9e2c658ae7a5e635df@haskell.org> #5280: System.Random commits (rand `mod` base) error. ------------------------------------------------+-------------------------- Reporter: rrnewton | Owner: Type: bug | rrnewton Priority: normal | Status: closed Component: libraries/random | Milestone: 7.10.1 Resolution: fixed | Version: 7.9 Operating System: Unknown/Multiple | Keywords: random Type of failure: Incorrect result at runtime | mod base Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:05:46 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.b3459e8d1f6089a5555531a95b3edef2@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: rrnewton Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/random | Version: 7.9 Resolution: fixed | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:28:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:28:32 -0000 Subject: [GHC] #7269: GeneralizedNewtypeDeriving and PolyKinds In-Reply-To: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> References: <046.1e47fafa481c78cda2f9c785dd9f4aa3@haskell.org> Message-ID: <061.b0dfe2eb623b6a38f3aab5fe46e44aa7@haskell.org> #7269: GeneralizedNewtypeDeriving and PolyKinds -------------------------------------------------+------------------------- Reporter: dreixel | Owner: Type: bug | dreixel Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.3 Operating System: Unknown/Multiple | Version: 7.6.1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T7269 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.3 Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:28:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:28:34 -0000 Subject: [GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken In-Reply-To: <047.7e804364d376ec9b9bd7772943568384@haskell.org> References: <047.7e804364d376ec9b9bd7772943568384@haskell.org> Message-ID: <062.6f9cbe16e56f2d2d7f50e2520d3f75d2@haskell.org> #9168: reading/writing blocking FDs over FD_SETSIZE is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: libraries/base | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.8.3 Comment: Merged into 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:37:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:37:03 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.87de6727e534af81b318ef33564001dd@haskell.org> #9163: Ptr should have a phantom role ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_compile/Roles2 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #9164 ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.10.1 Comment: I'm leaving these as is out of 7.8.3; I don't think they're critical, and some of the refactorings in `base` to `Data.Coerce` mean the original patches don't quite apply cleanly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:37:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:37:26 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.ca7715b488ed3a31bd17d3dc0bb5d3f1@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.4 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 18:57:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 18:57:05 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.b0f046e8a733af9a16af85c3b35f5e08@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by rwbarton): I managed to reproduce this by making a Frankenpackage from ghc HEAD plus the debian directory from `apt-get source ghc`. Here are the flags that are being used: {{{ rwbarton at morphism:/tmp$ ghc -optl-fPIE -optl-pie -optl-Wl,-z,relro -optl- Wl,-z,now test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... /usr/bin/ld: test.o: relocation R_X86_64_32S against `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC test.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status }}} `-optl-pie` is the offending flag. (`test.hs` is just a trivial program `main = print "hi"`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 19:20:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 19:20:07 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.2acba0715cff8f9cab7c86a62605adce@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks Reid! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 2 19:42:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jul 2014 19:42:01 -0000 Subject: [GHC] #8798: Missing symbols with -fprof-auto-calls In-Reply-To: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> References: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> Message-ID: <059.5c58e0f285241d6ae0833d5515f49af0@haskell.org> #8798: Missing symbols with -fprof-auto-calls -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => infoneeded Comment: I can't reproduce this any more in 7.8.1. I had to add an import for `runResourceT` and add `resourcet` to the cabal file, and I am using a sandbox for unrelated reasons, but I don't think that matters. Not sure if this is because the bug was fixed in 7.8.1 or the issue happened to go away due to building against newer versions of the dependencies. Can you reconstruct the versions of all the dependencies that were used when you reported this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 06:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 06:10:52 -0000 Subject: [GHC] #9259: GHCi should list its available command line options Message-ID: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> #9259: GHCi should list its available command line options -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- GHC can now list its command line options with `--show-options` (#7843). GHCi should be able to do the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 06:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 06:12:51 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.00c264c62634415e33cb6df219888e43@haskell.org> #9259: GHCi should list its available command line options -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jstolarek): Oh, and once this is done we should update [[GhcFile(driver/ghci- usage.txt)]] to inform user about this possibility (see [[GhcFile(driver /ghc-usage.txt)]] for an example). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 06:19:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 06:19:22 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.ff7c8573dcfec420df880934d80be819@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: jstolarek Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 08:08:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 08:08:47 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits Message-ID: <051.9b98f43647329b740144a23edc96d4be@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: type lits, data | Operating System: Linux kinds, error message | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling: {{{ {-# LANGUAGE DataKinds, TypeOperators, GADTs #-} module Error where import GHC.TypeLits data Fin n where Fzero :: Fin (n + 1) Fsucc :: Fin n -> Fin (n + 1) }}} gives a strange (unnecessary) error message claiming that `Fin 1` doesn't match the expected type `Fin (0 + 1)`: {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 % ghc -ignore-dot-ghci /tmp/Error.hs [1 of 1] Compiling Error ( /tmp/Error.hs, /tmp/Error.o ) /tmp/Error.hs:12:8: Couldn't match type ?0? with ?1? Expected type: Fin 1 Actual type: Fin (0 + 1) In the expression: Fsucc Fzero In an equation for ?test?: test = Fsucc Fzero /tmp/Error.hs:12:14: Couldn't match type ?1? with ?0? Expected type: Fin 0 Actual type: Fin (0 + 1) In the first argument of ?Fsucc?, namely ?Fzero? In the expression: Fsucc Fzero % }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 08:09:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 08:09:48 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits In-Reply-To: <051.9b98f43647329b740144a23edc96d4be@haskell.org> References: <051.9b98f43647329b740144a23edc96d4be@haskell.org> Message-ID: <066.e74df47a4b496484af472be539002fb0@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: type lits, data Operating System: Linux | kinds, error message Type of failure: Incorrect | Architecture: Unknown/Multiple warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Iceland_jack): Forgot to add the actual failing case: {{{ test :: Fin 1 test = Fsucc Fzero }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 09:22:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 09:22:01 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.3254b608a6f6c718cbbe22cd34bf988e@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * difficulty: Easy (less than 1 hour) => Unknown Comment: After a quick look at the source code I'm not sure if this is that simple. `--show-options` triggers pre-startup mode, which terminates the compiler before it even starts. But `ghci` is an alias for `ghc --interactive`, so we'd have to recognize a special case of `--interactive` and `--show- options` being used at the same time. That's probably possible, but it requires more work than I'm willing to put into this at the moment. Leaving this as a newcomer-friendly task. The relevant code is in [[GhcFile(ghc/Main.hs)]]. It is also important to distinguish which options are supported with GHCi and which are not. I'm not sure if this information is stored in one place somewhere in the compiler, but we need to have access to it. When this is fixed the user documentation needs to be updated as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 10:57:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 10:57:36 -0000 Subject: [GHC] #9256: Support automatic derivation of an hs-boot file from an hs file In-Reply-To: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> References: <045.8b36d4401d2cf222c4ddb4c787a0a219@haskell.org> Message-ID: <060.f153d792e913916fd387e251234955c5@haskell.org> #9256: Support automatic derivation of an hs-boot file from an hs file -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Bikeshedding syntax a little bit, here are two alternate way A.hs could be written: Inline annotations: {{{ module A where import B data Arf = MkArf (Maybe Bar) {-# BOOT_ABSTRACT #-} }}} Exclusionary (but as mentioned before, this syntax is a little problematic): {{{ module A where {-# BOOT_EXCLUDE Arf(..) #-} import B data Arf = MkArf (Maybe Bar) }}} Now to answer your questions: > An hs-boot file tends to have a mix of `{-# SOURCE #-}` imports and regular imports. The list of imports in the hs-boot file will be different than the list in the master file, and where the `{-# SOURCE #-}` pragma appears will be different. (There's a subset relationship between the import lists, of course.) How will this new syntax figure out which imports are necessary to type check the `BOOT_TYPES`? I imagine we'll have to augment the syntax to get all of the necessary information: I don't think it would be right to automatically compute it. However, I think the most common case is that of a simple mutual recursive group of two modules, in which case no changes to the imports are necessary. So I don't mind if the syntax just says directly, "This is a concrete import in the hs version, but a source import in the hs-boot version." (In Backpack-land, this case is probably common enough that it merits a shortcut. > It is sometimes desirable to include type definitions in hi-boot files. How does this syntax accommodate that need? I am not really sure what you mean by type definitions here, but surely they must still be defined in some way in the source file? Then we can annotate it to say that it should be included in the boot. Ditto with type synonyms and type families. I agree, there's a lot of syntax to be bikeshed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 12:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 12:58:37 -0000 Subject: [GHC] #9261: -S prints incorrect number of bound tasks Message-ID: <044.7e17b953c6f816789d43b1ec17f17162@haskell.org> #9261: -S prints incorrect number of bound tasks ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- In `Stats.c` we have: {{{ statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n", taskCount, taskCount - workerCount, peakWorkerCount, workerCount, n_capabilities); }}} but I think `taskCount - workerCount` must be wrong, because `taskCount` is the _current_ number of tasks, while `workerAcount` is the _total_ number of workers (accumulating). I think it should be: {{{ statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n", taskCount, taskCount - currentWorkerCount, peakWorkerCount, workerCount, n_capabilities); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 13:05:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 13:05:39 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.3bde968fd9657d0c34a504fd638c367c@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: 8299 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): > I attached nofib results comparing amd64 vs. x32 and i686 vs. x32; x32 is about 15% faster on average than either. Impressive. So that's our memory/cache penalty for having all our data structures 2x the size on x86-64 ABI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 14:55:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 14:55:29 -0000 Subject: [GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module In-Reply-To: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> References: <043.58b207491edf0ff815bfc192dd2fdf19@haskell.org> Message-ID: <058.30b37f85b71895ed6e45edaadab5e56f@haskell.org> #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -------------------------------------------------+------------------------- Reporter: bens | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.8.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | Architecture: Test Case: deriving/should_fail/T9071, | Unknown/Multiple T9071_2 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: This was actually merged and I missed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 15:56:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 15:56:50 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.f220eac2db2a77e7d2be2a49897df4be@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by RyanGlScott): I still experience this panic on GHC 7.8.2 with Windows x86_64: {{{ $ ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?> import StaticFlags ?> import Data.IORef ?> readIORef v_opt_C_ready Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package Win32-2.3.0.2 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.1.3 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.1 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.8.2 ... linking ... done. False ?> staticFlags ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But not with GHC 7.8.2 on Linux x86_64: {{{ $ ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?> import StaticFlags ?> import Data.IORef ?> readIORef v_opt_C_ready Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.1.3 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.1 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.8.2 ... linking ... done. True ?> staticFlags [] }}} This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 16:42:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 16:42:23 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances Message-ID: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> #9262: Allow free variables in reifyInstances ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $( do insts <- reifyInstances ''Eq [ListT `AppT` VarT (mkName "a")] runIO $ putStrLn $ pprint insts return [] ) }}} I get {{{ Bug.hs:7:4: Not in scope: type variable ?a? In the argument of reifyInstances: GHC.Classes.Eq [a] }}} But, I wanted the declaration for `instance Eq a => Eq [a]`. The error message isn't wrong, exactly -- `a` really isn't in scope -- but I think we can do better by just treating variables as fresh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 17:33:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 17:33:36 -0000 Subject: [GHC] #8288: add idris style EDSL support for deep embedding lambdas In-Reply-To: <045.64e9ea2f001334b7f4fdeaa66edde458@haskell.org> References: <045.64e9ea2f001334b7f4fdeaa66edde458@haskell.org> Message-ID: <060.9f4d38cd1852b5169fe6142e1664d832@haskell.org> #8288: add idris style EDSL support for deep embedding lambdas ----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ydewit): Would this be what is termed 'Syntax Overloading' in Idris documentation? One other related aspect is being able to overload error messages too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 22:27:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 22:27:08 -0000 Subject: [GHC] #9161: Pattern synonyms interact badly with data kinds In-Reply-To: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> References: <051.a4bd617eaa1666265ee94e2b2cb7b39f@haskell.org> Message-ID: <066.c1f6e7604913056bb0f1c83b2b72f851@haskell.org> #9161: Pattern synonyms interact badly with data kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: lowest | Milestone: 7.8.3 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: renamer, pattern Resolution: fixed | synonyms, data kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.3 Comment: This was merged into GHC 7.8 for 7.8.3 (part of fixing #9175). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 22:27:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 22:27:19 -0000 Subject: [GHC] #9018: GHC suppresses too much kind information In-Reply-To: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> References: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> Message-ID: <061.3f85c36d56d053fd3ec7fd608db52f79@haskell.org> #9018: GHC suppresses too much kind information -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.3 Comment: This was merged into GHC 7.8 for 7.8.3 (part of fixing #9175). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 22:27:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 22:27:34 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.aaab0a3fac61d60479aca223c536871e@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by thoughtpolice): This was merged into GHC 7.8 for 7.8.3 (also part of fixing #9175). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 22:27:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 22:27:40 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym In-Reply-To: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> References: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> Message-ID: <066.d93ae198299a6fbed1071d7738a0924f@haskell.org> #9023: Error when using empty record update on binary pattern synonym ------------------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: patsyn/should_compile/T9023 | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 22:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 22:27:59 -0000 Subject: [GHC] #9175: Bad interaction between Pattern Synonyms and Text In-Reply-To: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> References: <047.311a35a65ef21c36ac9cb789bb411456@haskell.org> Message-ID: <062.16210e5b37fd6fce18569305cf7fc943@haskell.org> #9175: Bad interaction between Pattern Synonyms and Text ---------------------------------------+----------------------------------- Reporter: emertens | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 23:27:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 23:27:11 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.4f1ec4fc824a4dc3b6c2d7e2d2c0049a@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > In some situations, GHC terminates successfully and generates a `dyn_o` > file, but no `dyn_hi` file. As a result, a package that contains a > library seems to build successfully, but fails to install. I narrowed > the problem down to the following test case. I compile it with `ghc > --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I > don't know how to trace it further. > > {{{ > module Foo where > import Text.ParserCombinators.Parsec > }}} > > Parsec was installed with `cabal install --reinstall --user --enable- > shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do > not cause the missing `dyn_hi` file. For instance, all output files are > created if Foo imports `Text.Parsec.Pos` instead of > `Text.ParserCombinators.Parsec`. > > My installed Parsec library seems to be working correctly. I can link > and run `main = parseTest (char 'a') "a"` in both `-dynamic` and > `-static` modes, and I can also use Parsec from GHCi. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don?t always produce desirable results. When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don?t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. Of the two cases described above, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but causes problems when it's used. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 23:31:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 23:31:13 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.55bb2ef97b748d0196b790db2eaa1e16@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > == Overview == > > In dynamic-too compilation, a module is compiled the normal way, then the > backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, > .dyn_hi) outputs. Compilation uses the .hi files of imported modules. > Effectively, the compiler assumes that all the information it gets from a > .hi file, used by the normal output, is also true of the corresponding > .dyn_hi file, used by the dynamic output. GHC has a few checks to verify > this, but they don?t always produce desirable results. > > When importing a module from a package in --make mode, GHC checks that > the normal and dynamic interfaces match, in `checkBuildDynamicToo` in > `findAndReadIface`. If they don?t match, GHC silently disables dynamic- > too, so that no dynamic interface file is produced. No errors or > warnings are reported. > > When importing a standalone module in --make mode, GHC does not examine > the dynamic interface at all. > > Of the two cases described above, GHC uses the weaker checks when > building a package and stricter checks when using the installed package. > The weaker checks allow a package with mismatched normal and dynamic > interface files to build and install without errors. After it's > installed, the stronger checks suppress the creation of .dyn_hi files > whenever the mismatched module is imported. Thus, a package installs > fine, but causes problems when it's used. > > == Reproducing == > > The attached code sets up an inconsistent pair of module interfaces and > runs both kinds of imports. To compile the first two files, build the > cabal package in `testcase9176/`. To compile the last file, install the > package, then run the makefile in `user/`. > > * `Imported.hs` is compiled with different optimization flags, setting up > a situation where the normal and dyamic module interfaces do not match. > > * `User.hs` importing directly `Imported.hs` loads only the static module > interface. The dynamic interface is ignored. > > * `User.hs` importing from the installed package `Imported.hs` compares > the static and dynamic interfaces, turns off dynamic-too compilation, and > does not generate a .dyn_hi file. No errors or warnings are produced. > > == Details == > > This bug appeared on my system in a Parsec module. Parsec installed with > no apparent problems, but other modules importing from Parsec would not > compile to .dyn_hi files. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don?t always produce desirable results. When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don?t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. Of the two cases described above, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but causes problems when it's used. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. This file is a copy of the other `User.hs`, just compiled differently. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 23:43:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 23:43:08 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.e9860f0012ba5794628717978aa8e8fb@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > == Overview == > > In dynamic-too compilation, a module is compiled the normal way, then the > backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, > .dyn_hi) outputs. Compilation uses the .hi files of imported modules. > Effectively, the compiler assumes that all the information it gets from a > .hi file, used by the normal output, is also true of the corresponding > .dyn_hi file, used by the dynamic output. GHC has a few checks to verify > this, but they don?t always produce desirable results. > > When importing a module from a package in --make mode, GHC checks that > the normal and dynamic interfaces match, in `checkBuildDynamicToo` in > `findAndReadIface`. If they don?t match, GHC silently disables dynamic- > too, so that no dynamic interface file is produced. No errors or > warnings are reported. > > When importing a standalone module in --make mode, GHC does not examine > the dynamic interface at all. > > Of the two cases described above, GHC uses the weaker checks when > building a package and stricter checks when using the installed package. > The weaker checks allow a package with mismatched normal and dynamic > interface files to build and install without errors. After it's > installed, the stronger checks suppress the creation of .dyn_hi files > whenever the mismatched module is imported. Thus, a package installs > fine, but causes problems when it's used. > > == Reproducing == > > The attached code sets up an inconsistent pair of module interfaces and > runs both kinds of imports. To compile the first two files, build the > cabal package in `testcase9176/`. To compile the last file, install the > package, then run the makefile in `user/`. > > * `Imported.hs` is compiled with different optimization flags, setting up > a situation where the normal and dyamic module interfaces do not match. > > * `User.hs` importing directly `Imported.hs` loads only the static module > interface. The dynamic interface is ignored. > > * `User.hs` importing from the installed package `Imported.hs` compares > the static and dynamic interfaces, turns off dynamic-too compilation, and > does not generate a .dyn_hi file. No errors or warnings are produced. > This file is a copy of the other `User.hs`, just compiled differently. > > == Details == > > This bug appeared on my system in a Parsec module. Parsec installed with > no apparent problems, but other modules importing from Parsec would not > compile to .dyn_hi files. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don?t always produce desirable results. When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don?t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. Of the two cases described above, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but causes problems when it's used. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. This file is a copy of the other `User.hs`, just compiled differently. == Problems == GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does not when compiling the third file. When compiling a module, GHC should read the interfaces of any modules that it imports. However, when compiling the second file, GHC does not read the .dyn_hi files describing the imported dynamic modules, only the .hi files describing the normal modules. The compiler does not treat mismatched module interfaces consistently in all situations, making it hard to find the root cause of errors. I'm not sure what the correct behavior should be. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 3 23:48:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jul 2014 23:48:33 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.ce23599de3d4508b9a74a441ab0304fe@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > == Overview == > > In dynamic-too compilation, a module is compiled the normal way, then the > backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, > .dyn_hi) outputs. Compilation uses the .hi files of imported modules. > Effectively, the compiler assumes that all the information it gets from a > .hi file, used by the normal output, is also true of the corresponding > .dyn_hi file, used by the dynamic output. GHC has a few checks to verify > this, but they don?t always produce desirable results. > > When importing a module from a package in --make mode, GHC checks that > the normal and dynamic interfaces match, in `checkBuildDynamicToo` in > `findAndReadIface`. If they don?t match, GHC silently disables dynamic- > too, so that no dynamic interface file is produced. No errors or > warnings are reported. > > When importing a standalone module in --make mode, GHC does not examine > the dynamic interface at all. > > Of the two cases described above, GHC uses the weaker checks when > building a package and stricter checks when using the installed package. > The weaker checks allow a package with mismatched normal and dynamic > interface files to build and install without errors. After it's > installed, the stronger checks suppress the creation of .dyn_hi files > whenever the mismatched module is imported. Thus, a package installs > fine, but causes problems when it's used. > > == Reproducing == > > The attached code sets up an inconsistent pair of module interfaces and > runs both kinds of imports. To compile the first two files, build the > cabal package in `testcase9176/`. To compile the last file, install the > package, then run the makefile in `user/`. > > * `Imported.hs` is compiled with different optimization flags, setting up > a situation where the normal and dyamic module interfaces do not match. > > * `User.hs` importing directly `Imported.hs` loads only the static module > interface. The dynamic interface is ignored. > > * `User.hs` importing from the installed package `Imported.hs` compares > the static and dynamic interfaces, turns off dynamic-too compilation, and > does not generate a .dyn_hi file. No errors or warnings are produced. > This file is a copy of the other `User.hs`, just compiled differently. > > == Problems == > > GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does > not when compiling the third file. > > When compiling a module, GHC should read the interfaces of any modules > that it imports. However, when compiling the second file, GHC does not > read the .dyn_hi files describing the imported dynamic modules, only the > .hi files describing the normal modules. > > The compiler does not treat mismatched module interfaces consistently in > all situations, making it hard to find the root cause of errors. > > I'm not sure what the correct behavior should be. > > == Details == > > This bug appeared on my system in a Parsec module. Parsec installed with > no apparent problems, but other modules importing from Parsec would not > compile to .dyn_hi files. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don?t always produce desirable results. When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don?t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. Of the two cases described above, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but importing from the package prevents dynamic-too compilation from working properly. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. This file is a copy of the other `User.hs`, just compiled differently. == Problems == GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does not when compiling the third file. When compiling a module, GHC should read the interfaces of any modules that it imports. However, when compiling the second file, GHC does not read the .dyn_hi file describing the imported dynamic module, only the .hi file describing the normal module. The compiler does not treat mismatched module interfaces consistently in all situations, making it hard to find the root cause of errors. I'm not sure what the correct behavior should be. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 00:59:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 00:59:51 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits In-Reply-To: <051.9b98f43647329b740144a23edc96d4be@haskell.org> References: <051.9b98f43647329b740144a23edc96d4be@haskell.org> Message-ID: <066.93ef70bb6412d3cbb754061f2e152187@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: type lits, data Operating System: Linux | kinds, error message Type of failure: Incorrect | Architecture: Unknown/Multiple warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by goldfire): The first error you report is certainly a bug. But, the second one is legitimate -- the type `Fin 1` has only 1 inhabitant, `Fzero`. Confirmed reproducible in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 01:43:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 01:43:07 -0000 Subject: [GHC] #9263: Iface type variable out of scope with default associated types and polykinds Message-ID: <047.8399d093a1731e650b621887335ccbf3@haskell.org> #9263: Iface type variable out of scope with default associated types and polykinds ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module A where import Data.Proxy class kproxy ~ 'KProxy => PEq (kproxy :: KProxy a) where type F (x :: a) :: Bool type F (x :: a) = False }}} {{{ {-# LANGUAGE DataKinds, KindSignatures, TypeFamilies #-} module B where import A import Data.Proxy data Void instance PEq ('KProxy :: KProxy Void) }}} {{{ module C where import B }}} Now, this happens in a terminal window: {{{ rae:21:38:44 ~/temp> ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) rae:21:38:46 ~/temp> ghc B.hs [2 of 2] Compiling B ( B.hs, B.o ) rae:21:38:47 ~/temp> ghc C.hs [3 of 3] Compiling C ( C.hs, C.o ) The interface for ?B? Declaration for R:FVoidx: Iface type variable out of scope: a Cannot continue after interface file error }}} If any two of the files are compiled together, the error does not occur. The emptiness of the `Void` type is irrelevant -- the error initially occurred with an inhabited type. This is a regression from 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 01:47:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 01:47:17 -0000 Subject: [GHC] #9264: Scoped kind variables do not work with default associated types Message-ID: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> #9264: Scoped kind variables do not work with default associated types ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- I have {{{ {-# LANGUAGE PolyKinds, TypeFamilies, ScopedTypeVariables #-} module Bug where class C (a :: k) where type F (a :: k) type F (a :: k) = Int }}} Compiling gives me {{{ Bug.hs:7:11: The signature specified kind ?k1?, but ?a? has kind ?k2? In the type ?(a :: k)? In the type instance declaration for ?F? In the class declaration for ?C? }}} The error is on the line declaring the default associated type for `F`. This happens in both 7.8.2 and HEAD. Having !ScopedTypeVariables causes no change, but I put it in the example to emphasize that adding !ScopedTypeVariables is not the solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 06:17:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 06:17:49 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits In-Reply-To: <051.9b98f43647329b740144a23edc96d4be@haskell.org> References: <051.9b98f43647329b740144a23edc96d4be@haskell.org> Message-ID: <066.31ec0273b581aa3879872f99648bcbac@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: type lits, data Operating System: Linux | kinds, error message Type of failure: Incorrect | Architecture: Unknown/Multiple warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes the second error is expected, the bug seems to occur for any finite set that is too small except the smallest example: {{{ Fzero :: Fin 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 07:29:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 07:29:34 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.525165a8174b9dd39ac4ae9a7a75ba0c@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jstolarek): I spent some time recently thinking about this one. It is not clear to me what should happen when we know that a type family `F` is injective. It would certainly allow us to infer from `(F a ~ F b)` that `a ~ b` (modulo corner cases). So instead of first reducing injective type family application and then working on the result we could instead reason about type family's arguments. We could even invert type families. Is there anything else we could reason about with injective type families? The discussion here is only about open type families (obviously, closed type families were not implemented two years ago). I guess that now this change would affect both open and closed type families? Replying to [comment:2 simonpj]: > Some functions might be injective in one argument but not another. For example: > {{{ > F a b ~ F c d ===> a ~ c > but not b ~ d > }}} That is not true according to the mathematical definition of injectivity (as stated in [comment:29 comment 29]). Unless we want to introduce definition of type families injective only in some of the arguments, [http://haskell.1045720.n5.nabble.com/Injective-type-families- tp3385084p3385684.html as proposed by Iavor]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 07:40:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 07:40:13 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.29806327ca2c44adf754499da32446ca@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 08:42:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 08:42:16 -0000 Subject: [GHC] #3569: ghci can't handle utf-8 chinese char correctly when modify. In-Reply-To: <044.9c568ba4db1530f0bbd9af30f9b67dee@haskell.org> References: <044.9c568ba4db1530f0bbd9af30f9b67dee@haskell.org> Message-ID: <059.9e24c043b28aa8b1c3b610308bd6789a@haskell.org> #3569: ghci can't handle utf-8 chinese char correctly when modify. -------------------------------------+---------------------------------- Reporter: guest | Owner: judah Type: bug | Status: closed Priority: normal | Milestone: ? Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thomie): * cc: hvr (added) * status: new => closed * resolution: => fixed Comment: Haskeline ticket [http://trac.haskell.org/haskeline/ticket/81 81], an my own testing, leads me to believe this issue has been fixed, at least on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 09:32:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 09:32:06 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.8f20549b6ca8a616aec208a1f3240fa9@haskell.org> #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 09:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 09:32:21 -0000 Subject: [GHC] #4259: Relax restrictions on type family instance overlap In-Reply-To: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> References: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> Message-ID: <059.32ca515a23de2b2d90ad5775e1eb79dd@haskell.org> #4259: Relax restrictions on type family instance overlap --------------------------------------------+------------------------------ Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8423 --------------------------------------------+------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 12:35:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 12:35:16 -0000 Subject: [GHC] #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux In-Reply-To: <047.6577d3b0e4350e5dc6e80e1809edc6cb@haskell.org> References: <047.6577d3b0e4350e5dc6e80e1809edc6cb@haskell.org> Message-ID: <062.07c2e693522d347c9daf3444197b4054@haskell.org> #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux -----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => invalid Comment: The current behavior is correct. From [http://www.polarhome.com/service/man/generic.php?qf=dlsym&type=2&of=OpenSuSE&sf=3 man dlsym]: "The symbols RTLD_DEFAULT and RTLD_NEXT are defined by only when _GNU_SOURCE was defined before including it." From System/Posix/DynamicLinker/Prim.hsc: -- On some host (e.g. SuSe Linux 7.2) RTLD_NEXT is not visible -- without setting _GNU_SOURCE. Since we don't want to set this -- flag, here's a different solution: You can use the Haskell -- function 'haveRtldNext' to check wether the flag is available -- to you. Ideally, this will be optimized by the compiler so -- that it should be as efficient as an #ifdef. -- If you fail to test the flag and use it although it is -- undefined, 'packOneModuleFlag' will bomb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 13:49:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 13:49:12 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.2605fb9822487769edd5fd78f3bb27ae@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by goldfire): I thinking about this ticket, I've imagined some syntax like this: {{{ type family FullyInjective a | Result -> a -- use a fun-dep-like syntax, where "Result" is a keyword, capitalized to avoid name-clashes with type variables type family Plus a b | Result a -> b, Result b -> a type family Only1stInjective a b | Result -> a }}} I could even imagine having dependencies among the arguments, though that might be a little strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 14:03:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 14:03:53 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.4aaae910f57f8674e53f98ae4eb04fef@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 14:43:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 14:43:01 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.71ae501c842a5e0830dadcb5eb9f88c3@haskell.org> #9159: cmm case, binary search instead of jump table --------------------------------------------+------------------------------ Reporter: wojteknar | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by arotenberg): For comparison: The Java Virtual Machine has two instructions called `tableswitch` and `lookupswitch`, which are normally implemented as a lookup table and a binary search, respectively. [http://cr.openjdk.java.net/~forax/lambda/src/share/classes/com/sun/tools/javac/jvm/Gen.java.html Here] is the code javac uses to decide whether to generate a `tableswitch` or `lookupswitch` for a `switch` statement: {{{ // Determine whether to issue a tableswitch or a lookupswitch // instruction. long table_space_cost = 4 + ((long) hi - lo + 1); // words long table_time_cost = 3; // comparisons long lookup_space_cost = 3 + 2 * (long) nlabels; long lookup_time_cost = nlabels; int opcode = nlabels > 0 && table_space_cost + 3 * table_time_cost <= lookup_space_cost + 3 * lookup_time_cost ? tableswitch : lookupswitch; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 15:15:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 15:15:15 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.ac5cc2676d2646e4311c4ff337c94797@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Here is an annoying problem for implementing this functionality. Module reexports should roughly be analogous to how we deal with type/declaration reexports at the Haskell source level. To briefly overview how that mechanism works, we have a phase of compilation called "renaming", which takes all identifiers and figures out what true names they refer to. This is done by consulting the hi files associated with imported modules, which record the original name of any identifiers they export. By analogy, the installed package information file is like an "hi" file, and we would like it to store a pointer to the original name of the module (in this case, the InstalledPackageId and original module name, if renaming is allowed.) However, there is trouble in paradise. Entries in the InstalledPackageDb are created by the Cabal library; however, the Cabal library has no knowledge about module resolution (it only looks at the dependencies to do dependency resolution): all of this logic is in GHC proper (Packages and Finder). So at the time Cabal is writing the installed package info, it would need to consult GHC in order to figure out where modules actually came from! This seems like a design smell. The alternative is to do module resolution in GHC. Here, we augment the creation of our module map (when processing `-package` flags) so that when we see a reexport, we consult the existing map and insert a pointer to precisely the original import. If the packages are passed to us in topologically sorted order (which Cabal seems to do today), then we only pay the cost of a single map lookup for every reexported module we encounter. The downside is that this mechanism is now no longer symmetric with original names. It's not really clear which one is better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 16:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 16:00:03 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.d7b3abace1c5bc906bdb33ff8f42be49@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Also, so minor UI things to watch out for: 1. Suppose a module Foo is defined by package a, and reexported by package b. I misspell my import and attempt to import module Fooo (sic). Clearly, when I give the list of corrections, I should only report Foo once. Now, suppose I have another module Foo defined by package c, so in our message we want to report that the module was found in multiple packages. In this case, we want to say "it was found in multiple packages: a (reexported by b), c" (and not just "a, c") 2. When we validate an entry in the installed package database, should we check if the reexported modules truly exist in the original package? Depending on what representation we have in the package database, this may not even be well defined. In any case, dependency validation should pick up most shenanigans. 3. In some functions, including packageDbModules from the GHC API, we asked to provide a `Module` for a re-exported module. Should the module returned be resolved to the original exporter, or still be the original name of the module? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 16:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 16:30:06 -0000 Subject: [GHC] #3178: Fix linking -lpthread for semaphores In-Reply-To: <047.4c07ab6c1ca5f755c6e1425bd544758d@haskell.org> References: <047.4c07ab6c1ca5f755c6e1425bd544758d@haskell.org> Message-ID: <062.5c227a9239764c6ef48b5a44bb4e96df@haskell.org> #3178: Fix linking -lpthread for semaphores -----------------------------------+------------------------------------ Reporter: sthibaul | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: libraries/unix | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4523 -----------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => fixed * related: => #4523 Comment: This issue should be fixed together with ticket #4523, commit [http://git.haskell.org/packages/unix.git/commit/dd0178b4803924d8326224362611caad2d69e0e4 dd0178b]. Proper autoconf test for sem_close's library; fixes trac #4523 Note: the current issue tracker for the `unix` library is at https://github.com/haskell/unix/issues -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 16:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 16:59:23 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.ca953aeea0f8358edb62552a31b8d86f@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): SPJ thought of a good way around the implementation problem: we should implement a "mini" module finder in ghc-pkg, which simply takes all of the dependencies listed in the package, and reads their entries in order to resolve a module reexport. We hold the invariant that reexports in the installed package database point to the original name, so once we find the relevant entry, we know the original name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 17:16:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 17:16:34 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information Message-ID: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> #9265: Extend PackageId to include version dependency information ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.9 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- [MultiInstances Multiple installed instances of a package] has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoCMultipleInstances GSoC project] that ultimately never got merged into HEAD. This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows: - We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`. - We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist. - We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice. - In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work. - We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 17:18:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 17:18:19 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.d834f4f2eca53670c305054b25bb03f8@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by ezyang: Old description: > [MultiInstances Multiple installed instances of a package] has been a > long sought after feature to alleviate Cabal hell, and was the subject of > an [GSoCMultipleInstances GSoC project] that ultimately never got merged > into HEAD. > > This ticket is our latest attack on the problem, summarized as: add a > version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) > associated with packages in the database. This approach is distinguished > from the prior attempts as follows: > > - We make no attempt to support multiple installations of different ways > or ABI-compatible versions of a library (e.g. with/without > optimizations.) This corresponds to supporting multiple > InstalledPackageIds in a database; in our case, we're supporting multiple > `PackageId`. > > - We do not have to deal with conflicting "instances" in GHC's package > resolver: multiple instances can be simultaneously loaded and used in a > single compiled program. This is because PackageIds are baked into the > exported linker symbols, so different versions will have different names > and can peacefully coexist. > > - We do not have to deal with the delicate ordering problem of > calculating an ABI hash when configuring a package, which is prior to > when we actually know it (ABI hash is only known after compilation), > because our hash is based ONLY on dependency resolution choice. > > - In absence of preference for previously installed packages, our Cabal > dependency resolution stays exactly the same: Cabal picks versions, and > from these choices we calculate the dependency hashes. With preference, > we will have to do a little more work. > > - We do not attempt to garbage collect old packages. Because we are not > dependent on ABI, there is not an explosion of installed pacakges from > package development; new installed packages only occur when version > numbers are bumped up, or packages are installed in a combinatorially > different fashion. New description: [wiki:Commentary/Packages/MultiInstances Multiple installed instances of a package] has been a long sought after feature to alleviate Cabal hell, and was the subject of an [wiki:Commentary/GSoCMultipleInstances GSoC project] that ultimately never got merged into HEAD. This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows: - We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`. - We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist. - We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice. - In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work. - We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 17:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 17:32:25 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.12a8e07a80f9bcf46642b21b3fc2047e@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): > We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist. What about packages that statically link against C libraries? Will we automatically mangle those C symbol names with the package version hash also? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 18:26:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 18:26:27 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.e2996078d98c4e4510148b248d49a2b7@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): No, C libraries won't get mangled; they'll be shared (in much the same way if two different Haskell packages ask for the same C library, they'll get the same one linked in.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 20:37:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 20:37:47 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory Message-ID: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Once a directory has around 2 million files in it, a lack of an accumulator in getDirectoryContents (unix version only; windows already has an acc) causes it to blow the stack: {{{ joey at darkstar:?/src/git-annex>cat test.hs import System.Directory main = do l <- getDirectoryContents "/tmp/big" print (null l) joey at darkstar:?/src/git-annex>ghc --make -O2 test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... joey at darkstar:?/src/git-annex>./test Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} I suggest the attached patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 20:43:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 20:43:12 -0000 Subject: [GHC] #9263: Iface type variable out of scope with default associated types and polykinds In-Reply-To: <047.8399d093a1731e650b621887335ccbf3@haskell.org> References: <047.8399d093a1731e650b621887335ccbf3@haskell.org> Message-ID: <062.84bd56d6c436555986120ad7da4e7156@haskell.org> #9263: Iface type variable out of scope with default associated types and polykinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I have a patch that fixes this, among other things. But it'll have to wait till I get back from holiday on 14 July. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 20:43:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 20:43:50 -0000 Subject: [GHC] #9264: Scoped kind variables do not work with default associated types In-Reply-To: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> References: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> Message-ID: <062.e66f149553b4c711d8c1a59e7ebfc6e1@haskell.org> #9264: Scoped kind variables do not work with default associated types -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I have a patch that fixes this, among other things. But it'll have to wait till I get back from holiday on 14 July. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 21:09:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 21:09:36 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.3c17e87accecd78955d9ea5d2627a0d1@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by joeyhess): While my patch avoids the stack overflow, getDirectoryContents still seems to be using more memory than I would expect if it's lazily generating the list of files. The test program uses around 600 mb. I think it also needs to use unsafeInterleaveIO, but have not been able to get that to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 21:19:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 21:19:18 -0000 Subject: [GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install In-Reply-To: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> References: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> Message-ID: <065.18ec8e35eb7d065772087dc9066df551@haskell.org> #9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Installing GHC | Difficulty: Moderate (less failed | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by MtnViewMark): Just a note for future readers: The reverse situation works fine. That is, a bindist built on a non-clang system will install fine on a clang system. The one invocation of gcc -E, for rts/dist/package.conf.install.raw, builds fine without the special clang preprocessor flags (-Wno-invalid-pp-token and -Wno-unicode). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 21:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 21:30:45 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.ffada71be8d073d003eaa57beb442bd4@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by joeyhess): I've gotten it to work with unsafePerformIO. I can provide a patch, but I don't think you'l find this approach acceptable. The problem is that any errors would be deferred until the list is consumed, ie the readFile problem all over again. With that said, it does work; the test program now uses only 1776kb, and a variant that gets the length of the list behaves similarly well. I wonder if it would be better to add a overDirectoryContents :: FilePath -> (FilePath -> IO ()) -> IO () or something like that? This would work in my particular use case, at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 22:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 22:23:43 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied Message-ID: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------+------------------------------------------------- Reporter: | Owner: danilo2 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Hello! The problem is not a bug related to proper code execution, but it affects the development in such way, we can treat it as a bug. Lets think about such simple code (it can be further simplified of course): {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} When trying to compile it using GHC-7.8, we get following error message: {{{#!haskell Illegal instance declaration for ?MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)? The liberal coverage condition fails in class ?MagicMerge? for functional dependency: ?m1 -> m2? Reason: lhs type ?UnsafeBase (UnsafeBase base err1) err2? does not determine rhs type ?UnsafeBase dstBase err1? In the instance declaration for ?MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)? }}} Which is of course right, but it is completely unhelpfull! When we run the same program against GHC-7.6, we get another message: {{{#!haskell No instance for (MagicMerge (UnsafeBase base err2) dstBase) arising from a use of `magicMerge' Possible fix: add an instance declaration for (MagicMerge (UnsafeBase base err2) dstBase) In the second argument of `($)', namely `magicMerge (Error e :: UnsafeBase base err2 a)' In the expression: Other $ magicMerge (Error e :: UnsafeBase base err2 a) In a case alternative: Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) }}} And it contains a very helpfull information about inferred types. The information is very helpfull, especialy with more complex instances. What is VERY IMPORTANT, when we use the inferred type, the code starts working in both, GHC-7.8 and GHC-7.6. Right now I have to use both versions of GHC to be able to develop my instances faster. So If we add the inferred by GHC-7.6 premise: {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance (MagicMerge (UnsafeBase base err2) dstBase) => MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} The code compiles and works ok in both GHC-7.6 and GHC-7.8. In such cases, GHC-7.8 should inform about lacking premises. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 22:26:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 22:26:50 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied In-Reply-To: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> References: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> Message-ID: <061.782746cee7c9113b2bc1948d80a609bb@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------------------------------+------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Description changed by danilo2: Old description: > Hello! The problem is not a bug related to proper code execution, but it > affects the development in such way, we can treat it as a bug. > > Lets think about such simple code (it can be further simplified of > course): > > {{{#!haskell > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE UndecidableInstances #-} > > data UnsafeBase base err val = Value val > | Error err > | Other (base val) > deriving (Show, Eq) > > class MagicMerge m1 m2 | m1 -> m2 where > magicMerge :: m1 a -> m2 a > > instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase > base err) where > magicMerge ma = case ma of > Value a -> Value a > Error e -> Error e > Other o -> o > > instance MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase > dstBase err1) where > magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma > of > Value a -> Value a > Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) > Other o -> case o of > Value a -> Other $ magicMerge (Value a :: UnsafeBase base > err2 a) > Error e -> Error e > Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base > err2 a) > > main = print "help me world!" > }}} > > When trying to compile it using GHC-7.8, we get following error message: > > {{{#!haskell > Illegal instance declaration for > ?MagicMerge > (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase > err1)? > The liberal coverage condition fails in class ?MagicMerge? > for functional dependency: ?m1 -> m2? > Reason: lhs type ?UnsafeBase (UnsafeBase base err1) err2? > does not determine rhs type ?UnsafeBase dstBase err1? > In the instance declaration for > ?MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase > dstBase err1)? > }}} > > Which is of course right, but it is completely unhelpfull! When we run > the same program against GHC-7.6, we get another message: > > {{{#!haskell > No instance for (MagicMerge (UnsafeBase base err2) dstBase) > arising from a use of `magicMerge' > Possible fix: > add an instance declaration for > (MagicMerge (UnsafeBase base err2) dstBase) > In the second argument of `($)', namely > `magicMerge (Error e :: UnsafeBase base err2 a)' > In the expression: > Other $ magicMerge (Error e :: UnsafeBase base err2 a) > In a case alternative: > Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) > }}} > > And it contains a very helpfull information about inferred types. The > information is very helpfull, especialy with more complex instances. > > What is VERY IMPORTANT, when we use the inferred type, the code starts > working in both, GHC-7.8 and GHC-7.6. Right now I have to use both > versions of GHC to be able to develop my instances faster. > > So If we add the inferred by GHC-7.6 premise: > > {{{#!haskell > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE UndecidableInstances #-} > > data UnsafeBase base err val = Value val > | Error err > | Other (base val) > deriving (Show, Eq) > > class MagicMerge m1 m2 | m1 -> m2 where > magicMerge :: m1 a -> m2 a > > instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase > base err) where > magicMerge ma = case ma of > Value a -> Value a > Error e -> Error e > Other o -> o > > instance (MagicMerge (UnsafeBase base err2) dstBase) => MagicMerge > (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where > magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma > of > Value a -> Value a > Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) > Other o -> case o of > Value a -> Other $ magicMerge (Value a :: UnsafeBase base > err2 a) > Error e -> Error e > Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base > err2 a) > > main = print "help me world!" > }}} > > The code compiles and works ok in both GHC-7.6 and GHC-7.8. In such > cases, GHC-7.8 should inform about lacking premises. New description: Hello! The problem is not a bug related to proper code execution, but it affects the development in such way, we can treat it as a bug. Lets think about such simple code (it can be further simplified of course): {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} When trying to compile it using GHC-7.8, we get following error message: {{{#!haskell Illegal instance declaration for ?MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)? The liberal coverage condition fails in class ?MagicMerge? for functional dependency: ?m1 -> m2? Reason: lhs type ?UnsafeBase (UnsafeBase base err1) err2? does not determine rhs type ?UnsafeBase dstBase err1? In the instance declaration for ?MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)? }}} Which is of course right, but is completely unhelpfull! When we run the same program against GHC-7.6, we get another message: {{{#!haskell No instance for (MagicMerge (UnsafeBase base err2) dstBase) arising from a use of `magicMerge' Possible fix: add an instance declaration for (MagicMerge (UnsafeBase base err2) dstBase) In the second argument of `($)', namely `magicMerge (Error e :: UnsafeBase base err2 a)' In the expression: Other $ magicMerge (Error e :: UnsafeBase base err2 a) In a case alternative: Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) }}} And it contains a very helpfull information about inferred types. The information is very usefull, especialy when developing more complex instances. It is VERY IMPORTANT to notice, that when we use the inferred context, the code compiles in both, GHC-7.8 and GHC-7.6! Right now I have to use both versions of GHC side by side, to be able to develop my instances faster. So If we add the context inferred by GHC-7.6: {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance (MagicMerge (UnsafeBase base err2) dstBase) => MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} The code compiles and works ok in both GHC-7.6 and GHC-7.8. In such cases, GHC-7.8 should inform about lacking premises. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 22:31:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 22:31:49 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied In-Reply-To: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> References: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> Message-ID: <061.6d7938ee8b03423ba816f1bbac433368@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------------------------------+------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by danilo2): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 22:38:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 22:38:04 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.7318d6132f99c8c74c182b55d01bdfb4@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by arotenberg): I don't have any great ideas on the LNE issue, other than maybe add a line in the GHC user docs about it somewhere. carter has opened #9251 for the min/max primops, so I guess this issue can be closed. Thanks for your help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 23:08:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 23:08:50 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.f1a14a39c695508ce2045e1af98f4a74@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I have a fix for this done, but not yet pushed. It'll have to wait till I get back from holiday. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 4 23:29:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jul 2014 23:29:59 -0000 Subject: [GHC] #9246: GHC generates poor code for repeated uses of min/max In-Reply-To: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> References: <049.6b9066f639c251d61cb8b2b3f8b36c7a@haskell.org> Message-ID: <064.25ee06863bd6fe316e893cd5cbb28044@haskell.org> #9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Comment (by carter): @arontenberg, need not close it per se, I think @simonpj raise a good point (which perhaps can be spun off into its own ticket?) I notice Jan has a blog post about LNE http://lambda.jstolarek.com/2013/10/let-no-escape/ is it kinda like a higher order phi function? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 08:05:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 08:05:15 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.4d5eb04314367c7c181c28ec20e0201e@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): This seems to be an instance of the problem described at http://www .joachim-breitner.de/blog/archives/620-Constructing-a-list-in-a-Monad.html (for which I have not found a suitable solution yet). Have you tried passing an a dlist in the accumulator? OTOH, it shouldn?t perform better than your first patch, just result in a different order... You say you use 7.8. Does this mean that the rumors that the stack would be unlimited in 7.8 are not true? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 14:59:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 14:59:01 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.4e5b89aa8e5ec82cab2133c237baf721@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory ----------------------------------------+---------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by joeyhess): * difficulty: Easy (less than 1 hour) => Unknown * version: 7.8.2 => 7.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 15:20:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 15:20:21 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.178c8747d08cd7656b26ed98fbfcbce1@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory ----------------------------------------+---------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by joeyhess): Sorry, had wrong ghc version entered before. It might indeed save some memory to deepseq the accumulator as described in the blog post. I have not tried, since in my use case I want to avoid buffering the whole list in memory at all. I'm currently using a getDirectoryContents' that uses unsafeInterleaveIO. To avoid exceptions being thrown after the call has succeeded, when the return list is traversed, I made it catch and discard exceptions from Posix.readDirStream etc, so in an exceptional condition the list may not contain all items in the directory. That was ok in my use case, but I dunno if it would be acceptable for the real getDirectoryContents. It would probably be fine to just fix it to not blow the stack, and perhaps add a note to its documentation that the list of directory contents is not streamed lazily. (Although note that eg, removeDirectoryRecursive uses getDirectoryContents and so can also unexpectedly use large amounts of memory..) I do wonder if conduit has a better way to handle this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 15:35:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 15:35:17 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.997901e1a65e12620232f4f8520991da@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory ----------------------------------------+---------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by joeyhess): One other idea: {{{ openDirectory :: FilePath -> IO DirHandle readDirectory :: DirHandle -> IO (Maybe FilePath) -- closes DirHandle automatically at end }}} If directory included that interface, then code that needs to stream the directory could easily do so. removeDirectoryRecursive could use that instead of getDirectoryContents and avoid ever using a lot of memory. It could also probably be used to make a conduit, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 16:16:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 16:16:08 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.a9e918eff3842c042c245fa6230c7729@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory ----------------------------------------+---------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nomeata): I was under the impression that people tend to think badly about lazy IO these days, so I?m not sure if it makes sense to make `getDirectoryContents` lazy. Unless of course most people expect it to be. I think a way forward is to make `getDirectoryContents` non-lazy, but not blowing the stack (if that still is a problem on 7.8), and alternatively think about an interface for people who need more control over that. Maybe http://hackage.haskell.org/package/filesystem-conduit-1.0.0.2/docs/Data- Conduit-Filesystem.html is already that solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 16:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 16:39:12 -0000 Subject: [GHC] #9268: internal error: evacuate(static): strange closure type -385875968 Message-ID: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 ----------------------------------+---------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- From a fresh checkout & "make -j3" build of "quick-llvm" profile. {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type -385875968 (GHC version 7.9.20140704 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) make[1]: *** Waiting for unfinished jobs.... <> make: *** [all] Error 2 }}} Host GHC: {{{ $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2") ,("Global Package DB","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 16:44:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 16:44:07 -0000 Subject: [GHC] #9268: internal error: evacuate(static): strange closure type -385875968 In-Reply-To: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> References: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> Message-ID: <058.4a1641c12801d70c5eb89c3844dd345b@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 ----------------------------------------+---------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Description changed by brbr: Old description: > From a fresh checkout & "make -j3" build of "quick-llvm" profile. > > {{{ > inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell > "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap > BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm > ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv > CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike > CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs > CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC > CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants > CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold > CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags > Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool > FastFunctions FastMutInt FastString FastTypes Finder Fingerprint > FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc > HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id > IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind > ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils > Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable > PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform > PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames > PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized > SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout > StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer > TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon > Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique > Util Var VarEnv VarSet" > dll-split: internal error: evacuate(static): strange closure type > -385875968 > (GHC version 7.9.20140704 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) > make[1]: *** Waiting for unfinished jobs.... > < residency (7 samples), 62M in use, 0.00 INIT (0.00 elapsed), 1.54 MUT > (3.48 elapsed), 0.35 GC (0.37 elapsed) :ghc>> > make: *** [all] Error 2 > }}} > > Host GHC: > > {{{ > $ ghc --info > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -fno-stack-protector") > ,("C compiler link flags","") > ,("ld command","/usr/bin/ld") > ,("ld flags","") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","YES") > ,("ld supports filelist","NO") > ,("ld is GNU ld","YES") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","True") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.2") > ,("Booter version","7.4.1") > ,("Stage","2") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","x86_64-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2") > ,("Global Package > DB","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2/package.conf.d") > ] > }}} New description: From a fresh checkout {{{ $ git describe ghc-7.9-start-4689-g0567a31 }}} and "make -j3" of the "quick-llvm" profile: {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type -385875968 (GHC version 7.9.20140704 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) make[1]: *** Waiting for unfinished jobs.... <> make: *** [all] Error 2 }}} Host GHC: {{{ $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2") ,("Global Package DB","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2/package.conf.d") ] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 16:44:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 16:44:24 -0000 Subject: [GHC] #9266: getDirectoryContents blow its stack in a huge directory In-Reply-To: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> References: <047.677eb60c498f5b2cff5e32ac5c401cad@haskell.org> Message-ID: <062.d941822e8e2aa30f02b0ddbe7c2b4b4f@haskell.org> #9266: getDirectoryContents blow its stack in a huge directory ----------------------------------------+---------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by joeyhess): Data.Conduit.Filesystem uses listDirectory to generate a list, and loops over it instead. listDirectory comes from system-fileio, and on Windows just uses getDirectoryContents. On unix, it essentially re-implements getDirectoryContents (unsure why). So, it does not avoid buffering [FilePath] in memory. But, looking at Data.Conduit.Filesystem, it could certianly be changed to use the openDirectory/readDirectory interface prototyped above and avoid that problem. Essentially, it would: liftIO (readDirectory h) >>= yield In fact, system-fileio has internally a similar openDir/readDir/closeDir, although that interface is not exported. So, I think adding that low-level interface to directory or somewhere and using it in conduit etc would be a good plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 17:42:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 17:42:58 -0000 Subject: [GHC] #9268: internal error: evacuate(static): strange closure type -385875968 In-Reply-To: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> References: <043.1b0896c34329d32a2c2042b8706f86ba@haskell.org> Message-ID: <058.1d9f0281e5f7930e2604990aa8dc52a2@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 ----------------------------------------+---------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by brbr): Issue not seen with "quick" profile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 18:48:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 18:48:14 -0000 Subject: [GHC] #9269: Type families returning quantified types Message-ID: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> #9269: Type families returning quantified types ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Is there a fundamental reason for not being able to use quantification in a type family? I'd very much like to be able to do it, obviously turning on RankNTypes if necessary. I'm looking for things like this: {{{#!haskell type family Foo (x :: Bool) where Foo True = forall a. [a] Foo False = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 18:56:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 18:56:05 -0000 Subject: [GHC] #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl Message-ID: <048.be06949b0a7679713a21d3fb371bcadd@haskell.org> #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I try to build the traverse-with-class package with GHC HEAD, I get an error: {{{ Data/Generics/Traversable/Instances.hs:21:1: Illegal type constructor or class name: ?c? When splicing a TH declaration: instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Data.Maybe.Maybe a_1) where Data.Generics.Traversable.Core.gtraverse = \f_2 x_3 -> case x_3 of Data.Maybe.Nothing -> Control.Applicative.pure Data.Maybe.Nothing Data.Maybe.Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Data.Maybe.Just) (f_2 arg_4) }}} This code used to compile with all the previous versions. Additionally, if I replace the TH splice with the generated instance declaration (with minimal corrections to make all names resolve), it is accepted: {{{ instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Maybe a_1) where gtraverse = \f_2 x_3 -> case x_3 of Nothing -> Control.Applicative.pure Nothing Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Just) (f_2 arg_4) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 21:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 21:15:02 -0000 Subject: [GHC] #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. Message-ID: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. -------------------------------------------+------------------------------- Reporter: brbr | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Avoid unnecessary clock_gettime() syscalls in GC stats. https://phabricator.haskell.org/D39 Avoiding the unnecessary call appears to save ~12ms of work per second. That's 17 minutes a day! Unsure if the frequency of this particular GC stats function for this `fib` program is the same for all Haskell programs.. Simple benchmark program with before/after `strace -c` output: {{{ fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) main = putStrLn $ show (fib 35) }}} Before: {{{ % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 52.73 0.110738 5 20318 clock_gettime 44.16 0.092733 5 20319 rt_sigprocmask 2.14 0.004503 8 532 rt_sigreturn 0.24 0.000514 21 25 mmap ... 0.00 0.000008 8 1 set_robust_list 0.00 0.000007 7 1 select ------ ----------- ----------- --------- --------- ---------------- 100.00 0.210001 41285 10 total }}} After: {{{ % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 59.24 0.094986 5 20319 rt_sigprocmask 36.85 0.059094 6 10161 clock_gettime 2.78 0.004463 8 527 rt_sigreturn 0.26 0.000417 17 25 mmap ... 0.00 0.000007 7 1 set_robust_list 0.00 0.000006 6 1 select ------ ----------- ----------- --------- --------- ---------------- 100.00 0.160354 31123 10 total }}} `nofib` results: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.0% 0.0% 0.10 0.10 0.0% ansi -0.0% 0.0% 0.00 0.00 0.0% atom -0.0% 0.0% +0.4% 0.0% 0.0% awards -0.0% 0.0% 0.00 0.00 0.0% banner -0.0% 0.0% 0.00 0.00 0.0% bernouilli -0.0% 0.0% 0.15 0.15 0.0% binary-trees -0.0% 0.0% +0.3% +0.3% 0.0% boyer -0.0% 0.0% 0.04 0.04 0.0% boyer2 -0.0% 0.0% 0.00 0.00 0.0% bspt -0.0% 0.0% 0.01 0.01 0.0% cacheprof -0.0% -0.0% +0.5% +0.5% +1.8% calendar -0.0% 0.0% 0.00 0.00 0.0% cichelli -0.0% 0.0% 0.08 0.08 0.0% circsim -0.0% 0.0% -0.6% -0.2% 0.0% clausify -0.0% 0.0% 0.03 0.03 0.0% comp_lab_zift -0.0% 0.0% 0.18 0.18 0.0% compress -0.0% 0.0% 0.15 0.15 0.0% compress2 -0.0% 0.0% 0.16 0.16 0.0% constraints -0.0% 0.0% -0.4% -0.2% 0.0% cryptarithm1 -0.0% 0.0% +0.4% +0.7% 0.0% cryptarithm2 -0.0% 0.0% 0.01 0.01 0.0% cse -0.0% 0.0% 0.00 0.00 0.0% eliza -0.0% 0.0% 0.00 0.00 0.0% event -0.0% 0.0% 0.14 0.14 0.0% exp3_8 -0.0% 0.0% 0.19 0.19 0.0% expert -0.0% 0.0% 0.00 0.00 0.0% fannkuch-redux -0.0% +0.0% +0.3% +0.1% 0.0% fasta -0.0% 0.0% +0.8% +1.2% 0.0% fem -0.0% 0.0% 0.02 0.02 0.0% fft -0.0% 0.0% 0.04 0.04 0.0% fft2 -0.0% 0.0% 0.05 0.05 0.0% fibheaps -0.0% 0.0% 0.02 0.02 0.0% fish -0.0% 0.0% 0.01 0.01 0.0% fluid -0.0% 0.0% 0.01 0.01 0.0% fulsom -0.0% 0.0% -2.3% -2.3% 0.0% gamteb -0.0% 0.0% 0.03 0.03 0.0% gcd -0.0% 0.0% 0.03 0.03 0.0% gen_regexps -0.0% 0.0% 0.00 0.00 0.0% genfft -0.0% 0.0% 0.04 0.04 0.0% gg -0.0% 0.0% 0.02 0.02 0.0% grep -0.0% 0.0% 0.00 0.00 0.0% hidden -0.0% 0.0% +1.0% +1.5% 0.0% hpg -0.0% 0.0% 0.17 0.17 0.0% ida -0.0% 0.0% 0.07 0.07 0.0% infer -0.0% 0.0% 0.06 0.06 0.0% integer -0.0% 0.0% -5.0% -4.9% 0.0% integrate -0.0% 0.0% 0.13 0.13 0.0% k-nucleotide -0.0% 0.0% -0.4% -0.4% 0.0% kahan -0.0% 0.0% -0.7% 0.0% 0.0% knights -0.0% 0.0% 0.01 0.01 0.0% lcss -0.0% 0.0% +1.3% +0.9% 0.0% life -0.0% 0.0% -2.4% -2.4% 0.0% lift -0.0% 0.0% 0.00 0.00 0.0% listcompr -0.0% 0.0% 0.07 0.07 0.0% listcopy -0.0% 0.0% 0.09 0.09 0.0% maillist -0.0% +0.0% 0.06 0.06 -1.1% mandel -0.0% 0.0% 0.06 0.06 0.0% mandel2 -0.0% 0.0% 0.00 0.00 0.0% minimax -0.0% 0.0% 0.00 0.00 0.0% mkhprog -0.0% 0.0% 0.00 0.00 0.0% multiplier -0.0% 0.0% 0.12 0.12 0.0% n-body -0.0% 0.0% +1.4% +1.5% 0.0% nucleic2 -0.0% 0.0% 0.05 0.05 0.0% para -0.0% 0.0% 0.0% 0.0% 0.0% paraffins -0.0% 0.0% 0.12 0.12 0.0% parser -0.0% 0.0% 0.03 0.03 0.0% parstof -0.0% 0.0% 0.00 0.00 0.0% pic -0.0% 0.0% 0.00 0.00 0.0% pidigits -0.0% 0.0% -0.4% -0.4% 0.0% power -0.0% 0.0% 0.0% +0.4% +3.6% pretty -0.0% 0.0% 0.00 0.00 0.0% primes -0.0% 0.0% 0.07 0.07 0.0% primetest -0.0% 0.0% 0.07 0.07 0.0% prolog -0.0% 0.0% 0.00 0.00 0.0% puzzle -0.0% 0.0% 0.14 0.14 0.0% queens -0.0% 0.0% 0.01 0.01 0.0% reptile -0.0% 0.0% 0.02 0.02 0.0% reverse-complem -0.0% 0.0% 0.12 0.12 0.0% rewrite -0.0% 0.0% 0.01 0.01 0.0% rfib -0.0% 0.0% 0.02 0.02 0.0% rsa -0.0% 0.0% 0.02 0.02 0.0% scc -0.0% 0.0% 0.00 0.00 0.0% sched -0.0% 0.0% 0.02 0.02 0.0% scs -0.0% 0.0% -0.8% -0.8% 0.0% simple -0.0% 0.0% 0.0% 0.0% 0.0% solid -0.0% 0.0% 0.13 0.13 0.0% sorting -0.0% 0.0% 0.00 0.00 0.0% spectral-norm -0.0% 0.0% 0.0% 0.0% 0.0% sphere -0.0% 0.0% 0.04 0.04 0.0% symalg -0.0% 0.0% 0.01 0.01 0.0% tak -0.0% 0.0% 0.01 0.01 0.0% transform -0.0% 0.0% 0.0% 0.0% 0.0% treejoin -0.0% 0.0% 0.16 0.16 0.0% typecheck -0.0% 0.0% 0.20 0.20 0.0% veritas -0.0% 0.0% 0.00 0.00 0.0% wang -0.0% 0.0% 0.13 0.13 0.0% wave4main -0.0% 0.0% 0.0% 0.0% 0.0% wheel-sieve1 -0.0% 0.0% 0.0% 0.0% 0.0% wheel-sieve2 -0.0% 0.0% -1.6% -2.4% 0.0% x2n1 -0.0% 0.0% 0.00 0.00 0.0% -------------------------------------------------------------------------------- Min -0.0% -0.0% -5.0% -4.9% -1.1% Max -0.0% +0.0% +1.4% +1.5% +3.6% Geometric Mean -0.0% -0.0% -0.3% -0.3% +0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 21:32:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 21:32:47 -0000 Subject: [GHC] #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. In-Reply-To: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> References: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> Message-ID: <058.455461d90bd9874be14bb63ac246f8e3@haskell.org> #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. -------------------------------+------------------------------------------- Reporter: brbr | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by rwbarton): Wow, nice catch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 5 23:24:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jul 2014 23:24:42 -0000 Subject: [GHC] #9272: Template Haskell doesn't support n+k patterns Message-ID: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> #9272: Template Haskell doesn't support n+k patterns ----------------------------+---------------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- ghci> runQ [d| foo (n+3) = 42 |] :1:6: Exotic pattern not (yet) handled by Template Haskell n+3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 00:05:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 00:05:58 -0000 Subject: [GHC] #9273: TypeNats and record syntax don't compile Message-ID: <042.f55b96da64f9fe90ae6a525656546bba@haskell.org> #9273: TypeNats and record syntax don't compile -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ #!haskell data SNat :: Nat -> * where SNatZ :: SNat 0 SNatS :: {sNatPred :: SNat n} -> SNat (n+1) }}} gives error {{{ rec_gadt_nat.hs:13:13: Could not deduce (n1 ~ n) from the context ((n + 1) ~ (n1 + 1)) bound by a pattern with constructor SNatS :: forall (n :: Nat). SNat n -> SNat (n + 1), in an equation for ?sNatPred? at rec_gadt_nat.hs:13:13-20 ?n1? is a rigid type variable bound by a pattern with constructor SNatS :: forall (n :: Nat). SNat n -> SNat (n + 1), in an equation for ?sNatPred? at rec_gadt_nat.hs:13:13 ?n? is a rigid type variable bound by the type signature for sNatPred :: SNat (n + 1) -> SNat n at rec_gadt_nat.hs:13:13 Expected type: SNat n Actual type: SNat n1 Relevant bindings include sNatPred :: SNat n1 (bound at rec_gadt_nat.hs:13:13) sNatPred :: SNat (n + 1) -> SNat n (bound at rec_gadt_nat.hs:13:13) In the expression: sNatPred In an equation for ?sNatPred?: sNatPred (SNatS {sNatPred = sNatPred}) = sNatPred }}} while {{{ #!haskell data SNat :: Nat -> * where SNatZ :: SNat 0 SNatS :: SNat n -> SNat (n+1) }}} works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 00:17:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 00:17:34 -0000 Subject: [GHC] #9273: TypeNats and record syntax don't compile In-Reply-To: <042.f55b96da64f9fe90ae6a525656546bba@haskell.org> References: <042.f55b96da64f9fe90ae6a525656546bba@haskell.org> Message-ID: <057.1ff1d0be66f875215ad4f90886952598@haskell.org> #9273: TypeNats and record syntax don't compile ----------------------------------------------+---------------------------- Reporter: br1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: That's because record syntax additionally defines an accessor function {{{ sNatPred :: SNat (n+1) -> SNat n sNatPred (SNatS x) = x }}} which you cannot define manually using the non-record syntax `SNat` either. As the error message says, GHC does not (yet) know that `n+1` determines `n`, so it cannot type check the above definition because as far as it is concerned, `x` might have type `SNat n1` for some other `n1` with `n1+1 = n+1`. Once the Nat solver is improved, your record syntax `SNat` should compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 06:04:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 06:04:58 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.293e2f288f4a4fb8f44117682b34e56c@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: jstolarek Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by dfeuer): I looked into what making -fwarn-tabs the default would break in the GHC tree, and the answer appears to be "very little". It looks like the only files that use tabs for layout, use -Werror, and don't specify -fno-warn- tabs are libraries/time/Test/{ShowDST.hs,TimeZone.hs,CurrentTime.hs} and a test file that's designed to break from the tab warning. So contrary to some initial fears thoughtpolice raised in IRC, it will *not* be necessary to detab the whole GHC source to make this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 07:50:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 07:50:08 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.4e7b622e9563dbaa3a11a75a40fba595@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): @jberthold: why not check the RTS version? It's in the RTS_IDENTIFIER event. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 08:56:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 08:56:37 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.e9f7de13b69885fe68af2aa64f344a3d@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jberthold): Replying to [comment:13 simonmar]: > @jberthold: why not check the RTS version? It's in the RTS_IDENTIFIER event. That would be possible, assuming that the event is indeed present in every trace (preferably near the beginning). The implementation has to "unwrap" all event blocks which group the event, though, which appears cumbersome. The more serious problem I see is parsing traces without this event: in order to restart with the proper block reason decoder, the parser needs to keep a reference to the input event stream (making it a list, not a stream), leading to memory issues for larger traces (and they do get large...) Identifying the version from header information is much cleaner, that is what the header is for. (OK, I admit that adding or extending an event for that purpose is a hack). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 10:38:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 10:38:51 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.c7a192ab8b980ddf0853d986be2830d5@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------ Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tulcod): * cc: tulcod (added) Comment: I have a similar issue. In particular, my cabal project defines a C source file which in turn calls a C function from a library (outside of my project). But since cabal repl tries to load the in-project .o file first, it encounters undefined symbols (in particular, it errors on a struct which is declared "extern" by the library). This is not influenced by the order of the "c-sources" and "extra- libraries" in my .cabal file. PS: overview of symbols: My C source file (in-project): function myfunc, which calls the C function libfunc Library C header file (outside project): declares somestruct as "extern"; defines libfunc "static inline", which uses a pointer to somestruct as an argument to libfunc_internal; declares libfunc_internal Library .so code: defines libfunc_internal, defines somestruct So "cabal repl" errors on "undefined symbol: somestruct" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 11:44:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 11:44:11 -0000 Subject: [GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI Message-ID: <042.a93530e65a57f7e254d144435628d197@haskell.org> #9274: GHC panic with UnliftedFFITypes+CApiFFI -----------------------------------+--------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following code fails to compile with at least GHC 7.6, 7.8 and HEAD: {{{#!hs import GHC.Prim import Foreign.C type GmpLimb = CULong type GmpSize = CLong -- mp_limb_t mpn_add_1 (mp_limb_t *rp, const mp_limb_t *s1p, mp_size_t n, mp_limb_t s2limb) foreign import capi unsafe "gmp.h mpn_add_1" c_mpn_add_1 :: MutableByteArray# s -> ByteArray# -> GmpSize -> GmpLimb -> IO GmpLimb }}} with the following compile error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140704 for x86_64-unknown-linux): toCType MutableByteArray# s Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Otoh, replacing `capi` with `ccall` makes the code compile just fine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 13:08:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 13:08:44 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.1d95cbf4ac6da2e2835d6b01c826dd00@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by arotenberg): Question: What "should" the behaviors of min and max be for the special cases of negative zero and NaN? Currently GHC does this: {{{ Prelude> min 0.0 (-0.0) :: Double 0.0 Prelude> min (-0.0) 0.0 :: Double -0.0 Prelude> min 0.0 (0.0/0.0) :: Double NaN Prelude> min (0.0/0.0) 0.0 :: Double 0.0 }}} The SSE instructions, at least, [http://x86.renejeschke.de/html/file_module_x86_id_173.html work similarly if you get the order right]: If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned). If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MINSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR. However, [http://en.wikipedia.org/wiki/IEEE_754_revision#min_and_max according to Wikipedia], IEEE 754-2008 specifies The min and max operations are defined but leave some leeway for the case where the inputs are equal in value but differ in representation. In particular: min(+0,?0) or min(?0,+0) must produce something with a value of zero but may always return the first argument. In order to support operations such as windowing in which a NaN input should be quietly replaced with one of the end points, min and max are defined to select a number, x, in preference to a quiet NaN: min(x,NaN) = min(NaN,x) = x max(x,NaN) = max(NaN,x) = x In the current draft, these functions are called minNum and maxNum to indicate their preference for a number over a quiet NaN. Some further comparisons: Java's `Math.min` [http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#min-double- double- specifies] Returns the smaller of two double values. That is, the result is the value closer to negative infinity. If the arguments have the same value, the result is that same value. If either value is NaN, then the result is NaN. Unlike the numerical comparison operators, this method considers negative zero to be strictly smaller than positive zero. If one argument is positive zero and the other is negative zero, the result is negative zero. The .NET Framework's `Math.Min` [http://msdn.microsoft.com/en- us/library/xcd487wd%28v=vs.110%29.aspx specifies] Parameter val1 or val2, whichever is smaller. If val1, val2, or both val1 and val2 are equal to NaN, NaN is returned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:17:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:17:02 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.20b05ea3c7da32a86fc5939e59337ed0@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I was able to reproduce this in 7.6 but not 7.8, so I assume it has been fixed by the switch to using dynamic libraries for TH. Please reopen if you find otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:26:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:26:45 -0000 Subject: [GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI In-Reply-To: <042.a93530e65a57f7e254d144435628d197@haskell.org> References: <042.a93530e65a57f7e254d144435628d197@haskell.org> Message-ID: <057.f3add98d614994ca914036f68c18ec35@haskell.org> #9274: GHC panic with UnliftedFFITypes+CApiFFI ---------------------------------------+----------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by hvr): Here's a simpler example (stolen from `Data.ByteString.Short.Internal` which uses `ccall`): {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE CApiFFI #-} {-# LANGUAGE UnliftedFFITypes #-} foreign import capi unsafe "string.h memcmp" c_memcmp_ByteArray :: ByteArray# -> ByteArray# -> CSize -> IO CInt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:43:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:43:44 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll Message-ID: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------+---------------------------------------- Reporter: ydewit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- See the following section from base's GHC.Event.Poll module: {{{ module GHC.Event.Poll ( new , available ) where #include "EventConfig.h" #if !defined(HAVE_POLL_H) import GHC.Base new :: IO E.Backend new = error "Poll back end not implemented for this platform" available :: Bool available = False {-# INLINE available #-} #else #include import Control.Concurrent.MVar (MVar, newMVar, swapMVar) import Control.Monad ((=<<), liftM, liftM2, unless) import Data.Bits (Bits, FiniteBits, (.|.), (.&.)) import Data.Maybe (Maybe(..)) import Data.Monoid (Monoid(..)) import Data.Word import Foreign.C.Types (CInt(..), CShort(..)) import Foreign.Ptr (Ptr) import Foreign.Storable (Storable(..)) import GHC.Base import GHC.Conc.Sync (withMVar) import GHC.Enum (maxBound) import GHC.Num (Num(..)) import GHC.Real (ceiling, fromIntegral) import GHC.Show (Show) import System.Posix.Types (Fd(..)) import qualified GHC.Event.Array as A import qualified GHC.Event.Internal as E }}} Note how there is a missing {{{import qualified GHC.Event.Internal as E}}} when {{{HAVE_POLL_H}}} is not defined. The same issue is present in master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:45:21 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.77dff30d61ababa6295c18bb6705d46a@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------------------+------------------------- Reporter: qnikst | Owner: Type: bug | Status: Priority: normal | closed Component: GHCi | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Linux | Keywords: Type of failure: GHCi crash | Architecture: Test Case: | Unknown/Multiple https://gist.github.com/qnikst/324a66914b3aba878be5| Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I can reproduce this in 7.6 and ghci's behavior is quite baffling to me, but happily 7.8 exhibits the expected behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:47:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:47:31 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll In-Reply-To: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> References: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> Message-ID: <060.3c4d643c8dca9672544be716e2e23e4f@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------------+---------------------------------- Reporter: ydewit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Description changed by ydewit: Old description: > See the following section from base's GHC.Event.Poll module: > {{{ > module GHC.Event.Poll > ( > new > , available > ) where > > #include "EventConfig.h" > > #if !defined(HAVE_POLL_H) > import GHC.Base > > new :: IO E.Backend > new = error "Poll back end not implemented for this platform" > > available :: Bool > available = False > {-# INLINE available #-} > #else > #include > > import Control.Concurrent.MVar (MVar, newMVar, swapMVar) > import Control.Monad ((=<<), liftM, liftM2, unless) > import Data.Bits (Bits, FiniteBits, (.|.), (.&.)) > import Data.Maybe (Maybe(..)) > import Data.Monoid (Monoid(..)) > import Data.Word > import Foreign.C.Types (CInt(..), CShort(..)) > import Foreign.Ptr (Ptr) > import Foreign.Storable (Storable(..)) > import GHC.Base > import GHC.Conc.Sync (withMVar) > import GHC.Enum (maxBound) > import GHC.Num (Num(..)) > import GHC.Real (ceiling, fromIntegral) > import GHC.Show (Show) > import System.Posix.Types (Fd(..)) > > import qualified GHC.Event.Array as A > import qualified GHC.Event.Internal as E > }}} > > Note how there is a missing {{{import qualified GHC.Event.Internal as > E}}} when {{{HAVE_POLL_H}}} is not defined. > > The same issue is present in master. New description: See the following section from base's GHC.Event.Poll module: {{{ module GHC.Event.Poll ( new , available ) where #include "EventConfig.h" #if !defined(HAVE_POLL_H) import GHC.Base new :: IO E.Backend new = error "Poll back end not implemented for this platform" available :: Bool available = False {-# INLINE available #-} #else #include import Control.Concurrent.MVar (MVar, newMVar, swapMVar) import Control.Monad ((=<<), liftM, liftM2, unless) import Data.Bits (Bits, FiniteBits, (.|.), (.&.)) import Data.Maybe (Maybe(..)) import Data.Monoid (Monoid(..)) import Data.Word import Foreign.C.Types (CInt(..), CShort(..)) import Foreign.Ptr (Ptr) import Foreign.Storable (Storable(..)) import GHC.Base import GHC.Conc.Sync (withMVar) import GHC.Enum (maxBound) import GHC.Num (Num(..)) import GHC.Real (ceiling, fromIntegral) import GHC.Show (Show) import System.Posix.Types (Fd(..)) import qualified GHC.Event.Array as A import qualified GHC.Event.Internal as E }}} Note how there is a missing {{{import qualified GHC.Event.Internal as E}}} when {{{HAVE_POLL_H}}} is not defined. The same issue is present in master. This is the error seen (note this is a custom haste build): {{{ Building base-4.7.0.0... Preprocessing library base-4.7.0.0... hastec: setNumCapabilities: not supported in the non-threaded RTS GHC/Event/Poll.hsc:18:11: Not in scope: type constructor or class ?E.Backend? }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:49:54 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll In-Reply-To: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> References: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> Message-ID: <060.9657106cce9732149de45b375c3e4cc3@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------------+---------------------------------- Reporter: ydewit | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by ydewit): * status: new => patch Comment: Here is the patch: {{{ diff --git a/GHC/Event/Poll.hsc b/GHC/Event/Poll.hsc index bb0b6e5..2ed25be 100644 --- a/GHC/Event/Poll.hsc +++ b/GHC/Event/Poll.hsc @@ -14,6 +14,7 @@ module GHC.Event.Poll #if !defined(HAVE_POLL_H) import GHC.Base +import qualified GHC.Event.Internal as E new :: IO E.Backend new = error "Poll back end not implemented for this platform" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:52:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:52:39 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.021e1f98652fd15a8ffc8e35413ba0fb@haskell.org> #9176: GHC not generating dyn_hi files -----------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Description changed by heatsink: Old description: > == Overview == > > In dynamic-too compilation, a module is compiled the normal way, then the > backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, > .dyn_hi) outputs. Compilation uses the .hi files of imported modules. > Effectively, the compiler assumes that all the information it gets from a > .hi file, used by the normal output, is also true of the corresponding > .dyn_hi file, used by the dynamic output. GHC has a few checks to verify > this, but they don?t always produce desirable results. > > When importing a module from a package in --make mode, GHC checks that > the normal and dynamic interfaces match, in `checkBuildDynamicToo` in > `findAndReadIface`. If they don?t match, GHC silently disables dynamic- > too, so that no dynamic interface file is produced. No errors or > warnings are reported. > > When importing a standalone module in --make mode, GHC does not examine > the dynamic interface at all. > > Of the two cases described above, GHC uses the weaker checks when > building a package and stricter checks when using the installed package. > The weaker checks allow a package with mismatched normal and dynamic > interface files to build and install without errors. After it's > installed, the stronger checks suppress the creation of .dyn_hi files > whenever the mismatched module is imported. Thus, a package installs > fine, but importing from the package prevents dynamic-too compilation > from working properly. > > == Reproducing == > > The attached code sets up an inconsistent pair of module interfaces and > runs both kinds of imports. To compile the first two files, build the > cabal package in `testcase9176/`. To compile the last file, install the > package, then run the makefile in `user/`. > > * `Imported.hs` is compiled with different optimization flags, setting up > a situation where the normal and dyamic module interfaces do not match. > > * `User.hs` importing directly `Imported.hs` loads only the static module > interface. The dynamic interface is ignored. > > * `User.hs` importing from the installed package `Imported.hs` compares > the static and dynamic interfaces, turns off dynamic-too compilation, and > does not generate a .dyn_hi file. No errors or warnings are produced. > This file is a copy of the other `User.hs`, just compiled differently. > > == Problems == > > GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does > not when compiling the third file. > > When compiling a module, GHC should read the interfaces of any modules > that it imports. However, when compiling the second file, GHC does not > read the .dyn_hi file describing the imported dynamic module, only the > .hi file describing the normal module. > > The compiler does not treat mismatched module interfaces consistently in > all situations, making it hard to find the root cause of errors. > > I'm not sure what the correct behavior should be. > > == Details == > > This bug appeared on my system in a Parsec module. Parsec installed with > no apparent problems, but other modules importing from Parsec would not > compile to .dyn_hi files. > > GHC was built from source, commit > 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with > XCode 5.1.1 on OS X 10.9.3. New description: == Overview == In dynamic-too compilation, a module is compiled the normal way, then the backend runs twice to generate normal (.o, .hi) and dynamic (.dyn_o, .dyn_hi) outputs. Compilation uses the .hi files of imported modules. Effectively, the compiler assumes that all the information it gets from a .hi file, used by the normal output, is also true of the corresponding .dyn_hi file, used by the dynamic output. GHC has a few checks to verify this, but they don?t always produce desirable results. * When importing a module from a package in --make mode, GHC checks that the normal and dynamic interfaces match, in `checkBuildDynamicToo` in `findAndReadIface`. If they don?t match, GHC silently disables dynamic- too, so that no dynamic interface file is produced. No errors or warnings are reported. * When importing a module (either from a package, or standalone) in one- shot mode with -c, GHC starts out the same way as above: it checks the imported interfaces, finds out they don't match, and disables dynamic-too output. After generating output the normal way, the compiler pipeline runs again in the dynamic way to generate the dynamic output. This seems to be the "right" thing to do. * When importing a standalone module in --make mode, GHC does not examine the dynamic interface at all. It generates both normal and dynamic output. Of the two --make cases, GHC uses the weaker checks when building a package and stricter checks when using the installed package. The weaker checks allow a package with mismatched normal and dynamic interface files to build and install without errors. After it's installed, the stronger checks suppress the creation of .dyn_hi files whenever the mismatched module is imported. Thus, a package installs fine, but importing from the package prevents dynamic-too compilation from working properly. == Reproducing == The attached code sets up an inconsistent pair of module interfaces and runs both kinds of imports. To compile the first two files, build the cabal package in `testcase9176/`. To compile the last file, install the package, then run the makefile in `user/`. * `Imported.hs` is compiled with different optimization flags, setting up a situation where the normal and dyamic module interfaces do not match. * `User.hs` importing directly `Imported.hs` loads only the static module interface. The dynamic interface is ignored. * `User.hs` importing from the installed package `Imported.hs` compares the static and dynamic interfaces, turns off dynamic-too compilation, and does not generate a .dyn_hi file. No errors or warnings are produced. This file is a copy of the other `User.hs`, just compiled differently. == Problems == GHC with -dynamic-too is expected to generate a .dyn_hi file, but it does not when compiling the third file. When compiling a module, GHC should read the interfaces of any modules that it imports. However, when compiling the second file, GHC does not read the .dyn_hi file describing the imported dynamic module, only the .hi file describing the normal module. The compiler does not treat mismatched module interfaces consistently in all situations, making it hard to find the root cause of errors. I'm not sure what the correct behavior should be. == Details == This bug appeared on my system in a Parsec module. Parsec installed with no apparent problems, but other modules importing from Parsec would not compile to .dyn_hi files. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 18:54:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 18:54:27 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll In-Reply-To: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> References: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> Message-ID: <060.305ee763b2d4b95bb9a148e328ddc318@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------------+---------------------------------- Reporter: ydewit | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:18:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:18:35 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.2ea49742fdc9e57229e99d6c2d7f23ad@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by carter): i'm working on that stuff, fret not! There's going to be a IEEE *must* conformance compliant version of every operation, plus a possibly system dependent one. It looks like IEEE actually specifies TWO versions of min and max. I've got a local copy of IEEE-754-2008 downloaded after I googled around, I'll spec out the operations later this week. Wrt the sign of 0 bit, it says `**may** always return the first argument` rather than **must**. Point being, the primops layer will likely have more than 1 variant, and the Num / Ord instances will have some choice of IEEE **must** condition + H2010 satisfying definition -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:27:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:27:44 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.e25ecb7472beb4c1633506b700ddd943@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): It depends on how "fundamental" a reason you want. Consider this: {{{ type family Foo (x :: Bool) where Foo True = forall a. a -> a -> a Foo False = () data SBool :: Bool -> * where STrue :: SBool True SFalse :: SBool False bar :: SBool b -> Foo b -> () bar STrue x = (x 'a' 'b', x True False) `seq` () bar SFalse x = x }}} It seems to be that it would be reasonable to expect the above code to typecheck, if we're allowed to write a family `Foo`. But, getting this to work wreaks havoc with the way GHC's typechecker is built. GHC walks over a term and builds up a set of constraints. For example, if the term is something like `z True`, then GHC will decide that `z` has type `alpha`, for some unknown type `alpha`. Then, it says that we must have `alpha ~ (beta -> gamma)`, from the fact that `z` is in a function position. We then see that `beta ~ Bool` from the type of `True`. After walking over an entire term, GHC then solves these constraints, in this case getting that the type of `z` must be `(Bool -> gamma)`. The crucial problem in the code above is that this algorithm runs into trouble on the RHS of the first clause of `bar`. GHC will see that `x` is used in a function position and will try to infer a type like `alpha -> beta` for `x`, which is dead wrong. "But wait," you say: "GHC can know that `x` should have type `forall a. a -> a -> a` by then!" Well, not quite. GHC knows that `x` has type `Foo b` (from the type signature) and that `b ~ True` (from the GADT pattern-match), but it hasn't yet put those pieces together: that's what the solver does! And, we don't want to try to run the solver before generating all the constraints, because the solver might do the wrong thing when it doesn't have enough information. One possible way forward here is to modify the offending line of the program above as follows: {{{ bar STrue (x :: forall a. a -> a -> a) = ... }}} Now, GHC knows the correct type of `x` on the RHS and can generate constraints there without a problem. When the solver runs, it needs to solve `Foo b ~ forall a. a -> a -> a`, which works out just fine, given the GADT pattern-match. This requirement (the extra type annotation) is strange and unexpected to users, who are likely not thinking about GHC's constraint-solving algorithm. Does this fact make your proposed feature a bad idea? I don't know. And, there may be yet other reasons why what you want is a bad idea; this one is just one possible reason. Do others know of other problems here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:28:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:28:02 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.4c8ae1509cc556fb5164bf9366a9e636@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by carter): actually, importantly, in section 5.11 of the 2008 standard they say Four mutually exclusive relations are possible: **less than** , **equal**, **greater than**, and **unordered**. The last case arises when at least one operand is NaN. Every NaN shall compare unordered with everything, including itself. Comparisons shall ignore the sign of zero (so +0 = ?0). Infinite operands of the same sign shall compare equal. thus the Ord compare based instance should actually perhaps throw an exception or otherwise fail when either argument is Nan? I'll need read a bit more. ANYWAY, theres several *distinct* semantics that can be chosen, and adding suitable support to ghc for the different semantics that aren't interexpressible is something I'll spend some time thinking about. don't worry, you'll have the version you want, but there will be an IEEE compliant one that also satisfies the corresponding haskell standard (BOTH, if they disagree theres a serious problem i'll have to have some discussion about) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:30:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:30:02 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.afe79067282b33ec6e7b5ed930d0eaf1@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by carter): Java is full of bad floating point design issues, not looking there for ANY design input. theres a fun rant here http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf As i'm a very hefty user of ghc for floating point computation, i'm going to be very very thoughtful on the design :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:36:22 -0000 Subject: [GHC] #9272: Template Haskell doesn't support n+k patterns In-Reply-To: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> References: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> Message-ID: <057.18d6ed54b63a4b885baa10c31ed46627@haskell.org> #9272: Template Haskell doesn't support n+k patterns ----------------------------------------------+---------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): n+k patterns are often seen as a misfeature and in fact were removed from Haskell 2010. See http://stackoverflow.com/questions/3748592/what-are-nk- patterns-and-why-are-they-banned-from-haskell-2010 for further discussion. I'm tempted to close as "wontfix" but want a concurring opinion before doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:43:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:43:17 -0000 Subject: [GHC] #9272: Template Haskell doesn't support n+k patterns In-Reply-To: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> References: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> Message-ID: <057.c89bbd589752437e876d0c5d2e0c201e@haskell.org> #9272: Template Haskell doesn't support n+k patterns ----------------------------------------------+---------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by thoughtpolice): I'm also inclined to mark as WONTFIX as well - GHC defaults to H2010 anyway. But I also won't close just yet - I'd also like a few more voices in here. If nobody else speaks up, then yes, I think this is going to be a WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:45:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:45:08 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance Message-ID: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:45:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:45:18 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.243c8625053ed9049a71bc62059fd218@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Initial CR: https://phabricator.haskell.org/D41 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:48:32 -0000 Subject: [GHC] #9277: audit ghc floating point support for IEEE (non)compliance Message-ID: <045.900a9761f5c523f4845987279dbc6b4d@haskell.org> #9277: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:55:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:55:06 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.5a4ad9cfb31e79206b76935a662d5436@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 19:55:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 19:55:13 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.dbf610c913219368b629e8ccface83ca@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 20:37:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 20:37:15 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll In-Reply-To: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> References: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> Message-ID: <060.7ff746efc0e363a18bd77af657f4bef2@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------------+---------------------------------- Reporter: ydewit | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Reid Barton ): In [changeset:"fa8553de237a2f91f8551d69ef604c1d8a007b5f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa8553de237a2f91f8551d69ef604c1d8a007b5f" Fix imports in GHC.Event.Poll when not HAVE_POLL_H (#9275) Though as far as I can tell, we can never successfully build under this configuration anyways: GHC.Event.TimerManager requires the Poll backend to be functional. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 20:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 20:37:41 -0000 Subject: [GHC] #9275: Missing import statement in GHC.Event.Poll In-Reply-To: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> References: <045.4c76f15c4e06543ffb74e54236fd9788@haskell.org> Message-ID: <060.7e42528182ae89a4587afeb3f986bc02@haskell.org> #9275: Missing import statement in GHC.Event.Poll ----------------------------------------+---------------------------------- Reporter: ydewit | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by rwbarton): * status: patch => closed * resolution: => fixed Comment: Thanks, applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 20:42:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 20:42:27 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.d5eb50e8e0991549a92a99c80beec17a@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by arotenberg): Yeah, I've seen those slides before. The problem with the arguments presented is that I know there is a class of users who demands "linguistically-legislated exact reproducibility" for floating-point computations, because I'm part of it! For my day job, I use Java to write a tool for modeling safety-critical software systems on desktop hardware. For our purposes, it is ''far'' more important that the results of the simulation be exactly identical across different platforms than it is they be numerically accurate or efficiently computable. We use Java's `strictfp` keyword and `StrictMath` class ubiquitously in our simulation engine, because it is essential that the output of our program be identical, no matter where or when it is run. When it is necessary to compute different or more numerically-accurate floating-point outputs, we emulate it in software. This is slow but allows us 100% confidence that you will always get the same results. That said, our application is a rare case. In most situations, faster and more accurate computations that can give slightly different results on different machines are preferable to calculations that are wrong in exactly-reproducible ways. Which section (if any) of the Haskell 2010 Report specifies the behavior of floating-point operations? I've glanced through it quickly but all I've been able to find is [https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 the Prelude definitions of the instances for Float and Double], which just list them as primitives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 21:56:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 21:56:23 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.ea4da0d99827aa34278b18fc58b4cf04@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9246 -------------------------------------+------------------------------------ Comment (by carter): To clarify what I said: both the perf and reproducible primops will be added and the one I'll pick for base will the reproducible/ portable one. We agree. Bring the worry to the code review once I've got a proposed patch. :-). I write tooling for both workloads, I'm well well well aware of reproducibility being valuable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 22:40:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 22:40:59 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.40bbc850d6604017d8e7062db0c57d9b@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by gintas): Is there anything keeping this patch from being applied? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 22:41:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 22:41:35 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.fc8f1116a952876f34f8b72173a42f58@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by gintas): The patch should be good to apply. Could someone take a closer look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 6 22:42:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jul 2014 22:42:58 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.b18f755b251b7ef2af2ee65f67511e50@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): No, I just haven't gotten to the outstanding patch queue. It's on my radar, don't worry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 02:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 02:45:05 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.c4d8ba08cea23fa1eb2ad3480c8ef351@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by rwbarton): I profiled GHC and ran it on Lennart's sample code. It spent quite a lot of time, 23.4% in `coercionKind.go`. Further investigation seemed to indicate that most of that time was spent in the `TyConAppCo` case, when called from `coercionRole`. I made the Functor and Applicative (and other) instances of `Pair` lazy in the pair, trying to avoid traversing the entire coercion when we only need the outermost type constructor. It did speed up the compilation significantly, from 25 seconds to 18 seconds: {{{ # current HEAD <> # with lazy Pair instances <> }}} However, it had almost no effect on compile allocations for any program in nofib. Perhaps the bad behavior is triggered by large list or record literals. There must be other regressions, since 7.6.3 takes only 9 seconds on my system. Also, I note that the object files produced by 7.8 or HEAD for Flags and Options are about 25% larger than those produced by 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 03:02:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 03:02:26 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.4ea2a890105669ca23f19c4e674c0212@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by goldfire): Hrm -- I'm responsible for the offending code. If `coercionRole` calling `coercionKind` is the hotspot that's taking the trouble, that only seems to happen from the `NthCo` case in `coercionRole`. It would be straightforward to add a `Role` field to `NthCo` to make `coercionRole` on an `NthCo` run in constant time. Would that solve this problem? I'm 95% sure that this change would be very straightforward. However, it seems that the change you made already mitigates the problem significantly. Let me know if I can help further! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 06:55:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 06:55:43 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.47f5efad02edd8f2caa1f1738049218d@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------+------------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8213 Type of failure: Other | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by dfeuer): * owner: => dfeuer * related: => #8213 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 07:53:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 07:53:17 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.d203c66535f1e074ffc4200373353a5b@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"55e7ab1210975e6276f3cab3ac0e1f35bcd772f0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="55e7ab1210975e6276f3cab3ac0e1f35bcd772f0" Do not print the result of 'main' after invoking ':main' (fixes #9086). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 07:53:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 07:53:57 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.1f4017daccd17fc04fa14740f0f02c41@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Sorry, I promised to push it but then it slipped my mind. Just validated and pushed. Congrats, Gintautas, for your first contribution to GHC! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 08:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 08:24:55 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.110c56a60bd70d7d45fdbf2ae25cab7d@haskell.org> #9156: Duplicate record field ------------------------------------------------+-------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: T9156 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by nomeata): Sorry for the delay. The refactoring patch lost your comment, and I believe the code could use some comments. Also, your `dropOneUnloc (unloc v)` could be a `deleteBy (\v' -> unloc v == unloc v')` or `deleteBy ((==) `on` unloc)`, unless I?m mistaken. This would make the code a tad smaller and easier to read (assuming you add a comment that states that it is important here that `deleteBy` deletes only the first occurence). Very minor, but I slightly tripped over `(L loc name : r') ++ go remSeen' rs`, and would not have tripped over `(L loc name) : r' ++ go remSeen' rs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:37:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:37:16 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.b51fc04ebfbbc91cfc12b48b665b9a2e@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): You're right, the `RTS_IDENTIFIER` event could be anywhere in the stream, possibly right at the end. We should put something in the header for this. Still, 7.8.2 was buggy and it's not a disaster if we don't support it properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:46:58 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found Message-ID: <045.813f344587210915a54c6a71c5a099a3@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found ----------------------------------+--------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9034, #8935 | ----------------------------------+--------------------------------- When given a Objective-C object file referencing a symbol available in a system framework, GHCi panics saying it can't find the symbol the object file relies on. {{{ $ cat >foo.m < BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ clang -c -o foo.o foo.m }}} {{{ $ ghci -v -framework Foundation foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /opt/ghc-7.8.2/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 --print-file-name libiconv.dylib Loading package base ... linking ... done. Loading object (static) foo.o ... Created temporary directory: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib foo.o -undefined dynamic_lookup -single_module -install_name '@rpath/ghc36377_1.dylib' -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -liconv *** Deleting temp files: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib *** Deleting temp dirs: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib, 9): Symbol not found: _OBJC_CLASS_$_NSThread Referenced from: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Expected in: flat namespace in /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note omitting `-framework Foundation` makes no difference to the output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:53:16 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.56674e05a6395441c386f32b758e9432@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9034, #8935 -------------------------------+------------------------------------------ Changes (by mietek): * keywords: => panic, dynamic linking * failure: None/Unknown => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:55:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:55:36 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.0d42c363d9716531b7386a75197d7f26@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------ Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by mietek): '''tulcod''', I opened #9277 to track an issue which appears similar to yours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:55:55 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.99cf9844c1a7c76ab680fa6fc6eca9f7@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9034, #9074, #8935 -------------------------------+------------------------------------------ Changes (by mietek): * related: #9034, #8935 => #9034, #9074, #8935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 10:58:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 10:58:42 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.64768503370baa83d23d05f213c6cc45@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9034, #9074, #8935 -------------------------------+------------------------------------------ Comment (by mietek): Works as expected in GHC 7.6.3: {{{ $ ghci foo.o GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... done final link ... ghc: lookupSymbol failed in relocateSection (relocate external) foo.o: unknown symbol `_OBJC_CLASS_$_NSThread' linking extra libraries/objects failed }}} {{{ $ ghci -framework Foundation foo.o GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... done Loading object (framework) Foundation ... done final link ... done > Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:36:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:36:21 -0000 Subject: [GHC] #9278: GHCi crash: Message-ID: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> #9278: GHCi crash: ------------------------------------------+------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: crash, dynamic linking | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9277 | ------------------------------------------+------------------------------- Given an Objective-C object file referencing a symbol available in a system framework, interactive GHCi 7.6.3 crashes in an odd fashion. Start with an Objective-C source file, defining a function to be used via the FFI: {{{ $ cat >foo.m < BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ cat >Main.hs < main 2014-07-07 12:28:21.811 ghc[37395:1103] *** NSForwarding: warning: selector (0x10ddef328) for message 'isMainThread' does not match selector known to Objective C runtime (0x7fff8ea15881)-- abort 2014-07-07 12:28:21.813 ghc[37395:1103] +[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280 2014-07-07 12:28:21.814 ghc[37395:1103] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280' *** First throw call stack: ( 0 CoreFoundation 0x00007fff8bb4825c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x00007fff85029e75 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8bb4b02d +[NSObject(NSObject) doesNotRecognizeSelector:] + 205 3 CoreFoundation 0x00007fff8baa6322 ___forwarding___ + 1010 4 CoreFoundation 0x00007fff8baa5ea8 _CF_forwarding_prep_0 + 120 5 ??? 0x000000010ddef31a 0x0 + 4527682330 6 ??? 0x000000010ddf02f5 0x0 + 4527686389 ) libc++abi.dylib: terminating with uncaught exception of type NSException Abort trap: 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:38:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:38:40 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.4696d0b0e8ae873e498890736fadac52@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9034, #9074, #8935 -------------------------------+------------------------------------------ Description changed by mietek: Old description: > When given a Objective-C object file referencing a symbol available in a > system framework, GHCi panics saying it can't find the symbol the object > file relies on. > > {{{ > $ cat >foo.m < #import > > BOOL is_main_thread() > { > return [NSThread isMainThread]; > } > EOF > }}} > {{{ > $ clang -c -o foo.o foo.m > }}} > {{{ > $ ghci -v -framework Foundation foo.o > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version > 7.6.3 > Using binary package database: > /opt/ghc-7.8.2/lib/ghc-7.8.2/package.conf.d/package.cache > wired-in package ghc-prim mapped to ghc- > prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 > wired-in package integer-gmp mapped to integer- > gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 > wired-in package base mapped to > base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 > wired-in package rts mapped to builtin_rts > wired-in package template-haskell mapped to template- > haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Hsc static flags: > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > *** gcc: > /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE > -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 --print-file-name > libiconv.dylib > Loading package base ... linking ... done. > Loading object (static) foo.o ... Created temporary directory: > /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 > *** Linker: > /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 > -dynamiclib -o > /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib > foo.o -undefined dynamic_lookup -single_module -install_name > '@rpath/ghc36377_1.dylib' -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 > -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 > -L/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath > -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 > -L/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath > -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 > -L/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath > -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 > -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -liconv > *** Deleting temp files: > Deleting: > /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib > *** Deleting temp dirs: > Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib, > 9): Symbol not found: _OBJC_CLASS_$_NSThread > Referenced from: > /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib > Expected in: flat namespace > in > /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Note omitting `-framework Foundation` makes no difference to the output. New description: When given a Objective-C object file referencing a symbol available in a system framework, interactive GHCi 7.8.2 panics saying it can't find the symbol the object file relies on. Start with an Objective-C source file, defining a function to be used via the FFI: {{{ $ cat >foo.m < BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ cat >Main.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:39:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:39:26 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.7ea944e65c61b06f0f55965e2010ab82@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found ----------------------------+---------------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935, #9034, #9074, #9278 Blocking: | ----------------------------+---------------------------------------------- Changes (by mietek): * related: #9034, #9074, #8935 => #8935, #9034, #9074, #9278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:40:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:40:06 -0000 Subject: [GHC] #9279: Optimisation bug Message-ID: <047.2731319b9773852326eb9e6a852376dc@haskell.org> #9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:40:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:40:56 -0000 Subject: [GHC] #9279: Optimisation bug In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.012026cd0e6529ebd1652d0aae85054e@haskell.org> #9279: Optimisation bug --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:46:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:46:01 -0000 Subject: [GHC] #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime (was: GHCi crash:) In-Reply-To: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> References: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> Message-ID: <060.7797c1397b2d2e5e9bf85c332c7233a4@haskell.org> #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: crash, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9277 -------------------------------+------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 11:47:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 11:47:17 -0000 Subject: [GHC] #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime In-Reply-To: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> References: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> Message-ID: <060.da9393101127d5005f4b65db3defdc06@haskell.org> #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime -------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: crash, dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9277 -------------------------------+------------------------------------------ Comment (by mietek): There is a similar issue in GHC 7.8.2: #9277 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:01:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:01:25 -0000 Subject: [GHC] #9280: GHCi crash: Message-ID: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> #9280: GHCi crash: ------------------------------------------+-------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: crash, dynamic linking | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: ------------------------------------------+-------------------------------- Given a statically-linked Haskell object file, interactive GHCi 7.8.2 crashes. {{{ $ cat >Foo.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:01:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:01:49 -0000 Subject: [GHC] #9280: GHCi crash: illegal text-relocation (was: GHCi crash:) In-Reply-To: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> References: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> Message-ID: <060.3c9dc66f2757c531ef1e2ba6b06d41bb@haskell.org> #9280: GHCi crash: illegal text-relocation --------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: crash, dynamic linking Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | --------------------------------+------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:03:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:03:12 -0000 Subject: [GHC] #9280: GHCi crash: illegal text-relocation; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object (was: GHCi crash: illegal text-relocation) In-Reply-To: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> References: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> Message-ID: <060.857eb3681d99135ce73a7cb04d865441@haskell.org> #9280: GHCi crash: illegal text-relocation; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object --------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: crash, dynamic linking Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | --------------------------------+------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:05:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:05:50 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions Message-ID: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. This rewrite can be done incrementally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:17:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:17:36 -0000 Subject: [GHC] #9280: GHCi crash: illegal text-relocation; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object In-Reply-To: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> References: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> Message-ID: <060.80dbbb9d0d928c7a677d5c41797dc13e@haskell.org> #9280: GHCi crash: illegal text-relocation; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object --------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: crash, dynamic linking Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | --------------------------------+------------------------------------------ Comment (by mietek): As discussed on IRC with '''rwbarton''', it's questionable whether this is an issue besides "you're not supposed to do this". On one hand, GHCi claims it can load object files, and GHCi 7.6.3 does not crash when fed with an `.o` file produced by itself. On the other hand, feeding an `.o` file to GHCi 7.6.3 is not useful, as there is apparently no way to bring the functions declared in the corresponding `.hi` file into scope. I see two solutions ? either adjust user expectations, or allow feeding GHCi explicitly with `.o`/`.hi` pairs, in the absence of an `.hs` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:20:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:20:06 -0000 Subject: [GHC] #9280: GHCi crash: illegal text-relocation to _ in _ from _ in _ for architecture x86_64; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object (was: GHCi crash: illegal text-relocation; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object) In-Reply-To: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> References: <045.75366a6d8bb8f153b367bf0a7d539b25@haskell.org> Message-ID: <060.399fe4516659ea660055616ff2d780a0@haskell.org> #9280: GHCi crash: illegal text-relocation to _ in _ from _ in _ for architecture x86_64; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object --------------------------------+------------------------------------------ Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: crash, dynamic linking Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | --------------------------------+------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:28:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:28:03 -0000 Subject: [GHC] #9282: GHCi ignores .dyn_hi files Message-ID: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> #9282: GHCi ignores .dyn_hi files ----------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- With both `.o` and `.dyn_o` object files available, GHCi 7.8.2 ignores the dynamic object files. {{{ $ cat >Foo.hs < :l Foo [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. > }}} As '''rwbarton''' mentioned on IRC, the reason becomes apparent with `ghci -ddump-if-trace` {{{ FYI: cannot read old interface file: mismatched interface file ways (wanted "dyn", got "") }}} This happens both on OS X and Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:29:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:29:13 -0000 Subject: [GHC] #9282: GHCi ignores .dyn_hi files In-Reply-To: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> References: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> Message-ID: <060.4c147e2e97d4f5cb187c6f2cdaffbcf9@haskell.org> #9282: GHCi ignores .dyn_hi files -------------------------------------+----------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: dynamic linking Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------------- Changes (by mietek): * keywords: => dynamic linking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:32:21 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" In-Reply-To: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> References: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> Message-ID: <060.830f7dde4997aa4e5c248eae21246ae2@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ---------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by mietek): '''carter''', is this fixed by #8683? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:32:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:32:58 -0000 Subject: [GHC] #9282: GHCi ignores .dyn_hi files In-Reply-To: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> References: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> Message-ID: <060.b55b4a3132e13c0e5f3ee95b5f4d490e@haskell.org> #9282: GHCi ignores .dyn_hi files -------------------------------------+----------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: dynamic linking Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------------- Comment (by rwbarton): It also ignores the `.dyn_o` file even if there is no `.o` file, with no pertinent output from `-ddump-if-trace`: {{{ *** Checking old interface for main:F: [1 of 1] Compiling F ( F.hs, interpreted ) }}} (I am running 7.8.2.20140630.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 15:35:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 15:35:45 -0000 Subject: [GHC] #9282: GHCi ignores .dyn_o files (was: GHCi ignores .dyn_hi files) In-Reply-To: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> References: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> Message-ID: <060.87879f9a2ae0c31942844fc8d89e2f36@haskell.org> #9282: GHCi ignores .dyn_o files -------------------------------------+----------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: dynamic linking Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 16:44:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 16:44:14 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.82caa6a57c5f34a26ebc23fbd48adbb1@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by mietek): With 7.8.2, using `import Foreign.C.Types (CInt)` still results in the unclear error message: {{{ Unacceptable argument type in foreign declaration: CInt }}} Using `import Foreign.C.Types (CInt (..))` helps, but should this be required? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 17:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 17:04:23 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.c8e58060483a56e2d3234f99cb991c51@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: 8299 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): related to the x32 matter, theres apparently some leg work by Intel to add / improve x32 support in LLVM and GCC and related bits http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074451.html https://sites.google.com/site/x32abi/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 17:43:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 17:43:35 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.eb809a1be3ee36cd2ade4a74994d0e4e@haskell.org> #9234: Compiled code performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Description changed by augustss: Old description: > Upgrading from ghc 7.6 to 7.8 has slowed down our main application > noticeably. This is with 32-bit Windows. > > Here's some 7.2 numbers: > {{{ > INIT time 0.00s ( 0.00s elapsed) > MUT time 287.78s (290.41s elapsed) > GC time 87.39s ( 88.43s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 375.63s (378.86s elapsed) > }}} > > And corresponding 7.8 numbers: > {{{ > INIT time 0.00s ( 0.00s elapsed) > MUT time 298.34s (301.35s elapsed) > GC time 88.16s ( 89.27s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 386.93s (390.62s elapsed) > }}} > > This is not unexpected since every ghc upgrade so far has slowed down out > code; it's just following the trend we expect. New description: Upgrading from ghc 7.6 to 7.8 has slowed down our main application noticeably. This is with 32-bit Windows. Here's some 7.2 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 287.78s (290.41s elapsed) GC time 87.39s ( 88.43s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 375.63s (378.86s elapsed) }}} And corresponding 7.8 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 298.34s (301.35s elapsed) GC time 88.16s ( 89.27s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 386.93s (390.62s elapsed) }}} This is not unexpected since every ghc upgrade so far has slowed down our code; it's just following the trend we expect. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 17:43:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 17:43:47 -0000 Subject: [GHC] #9283: bad autoconf variable names Message-ID: <047.5cbd260f6e99ea132d099350fc2478de@haskell.org> #9283: bad autoconf variable names ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ if test "$ac_cv_header_sys_epoll_h" = yes -a "$ac_cv_func_epoll_ctl" = yes; then AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.]) fi if test "$ac_cv_header_sys_event_h" = yes -a "$ac_cv_func_kqueue" = yes; then AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.]) AC_CHECK_SIZEOF([kev.filter], [], [#include struct kevent kev;]) AC_CHECK_SIZEOF([kev.flags], [], [#include struct kevent kev;]) fi if test "$ac_cv_header_poll_h" = yes -a "$ac_cv_func_poll" = yes; then AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.]) fi }}} The `AC_DEFINE` lines for `HAVE_KQUEUE` and `HAVE_POLL` don't do anything, because earlier we have {{{ AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll]) }}} and that already defines `HAVE_KQUEUE` (and sets `ac_cv_func_kqueue`) when the `kqueue` function is found. Not entirely sure what the right thing to do is here, do we rely on having a prototype for `kqueue` in `sys/event.h` specifically? Technically that wouldn't be what we check for even if we used a renamed `HAVE_KQUEUE` variable. AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having `poll` by moving `/usr/include/poll.h` away temporarily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 18:03:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 18:03:50 -0000 Subject: [GHC] #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl In-Reply-To: <048.be06949b0a7679713a21d3fb371bcadd@haskell.org> References: <048.be06949b0a7679713a21d3fb371bcadd@haskell.org> Message-ID: <063.47ed84db0b1dd76654e1ac15977a80ad@haskell.org> #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: The code in `traverse-with-class` is incorrect and should lead to exactly this error. It calls `classP` on a type variable `c`. `classP` is meant to make a class-predicate, and should be passed the name of a class, not a type variable. The fact that this worked previously was in error. To be fair, using a type variable in a constraint was not possible before GHC 7.9, so the author of `traverse-with-class` didn't really have another choice. Now that TH supports a full variety of constraints, the code can be rewritten to use `AppT` and `VarT` instead of `classP`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 18:11:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 18:11:34 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.fe121f59afe2d442bd13d9e7270d49b5@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by carter): Agreed with Simon, especially since event log support was pretty busted with 7.8.2 anyways (eg: user events didn't seem to show up correctly!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 19:12:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 19:12:58 -0000 Subject: [GHC] #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl In-Reply-To: <048.be06949b0a7679713a21d3fb371bcadd@haskell.org> References: <048.be06949b0a7679713a21d3fb371bcadd@haskell.org> Message-ID: <063.fa4e9ab8353aa6e00c8e614c7b2773cc@haskell.org> #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): That helped, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 21:53:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 21:53:55 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.81a63a0be92b27195fac01bdf5b2c691@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by rwbarton): Lennart's program seems to be hitting a strange behavior in the simplifier. I managed to extract a relatively simple test case on which ghc 7.8 is much slower than 7.6. With `-v3` I see output like this (may be for a slightly different version): {{{ ... *** Demand analysis: Result size of Demand analysis = {terms: 274, types: 282, coercions: 3} *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 642, types: 692, coercions: 3} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 519, types: 669, coercions: 556} <---- !!! Result size of Simplifier iteration=2 = {terms: 285, types: 329, coercions: 3} Result size of Simplifier = {terms: 285, types: 329, coercions: 3} ... }}} The program is sensitive to changes in various ways. Doubling the number of fields in `X` doubles the number of coercions on that line, and increases ghc's runtime by a factor of about 16. Reducing the number of fields in `Options` to ten or fewer eliminates this spike in coercions completely! And changing `" "` to `""` eliminates the excess conversions, too. My laziness change to Pair seems to only help in this pathological case, and it slightly hurts on any other program I have tried. So better to track down and avoid this bad behavior in the simplifier, and leave `coercionKind` and friends alone, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 22:40:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 22:40:06 -0000 Subject: [GHC] #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. In-Reply-To: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> References: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> Message-ID: <058.608837c8b2cec951dc1533fb0a42b8ca@haskell.org> #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. -------------------------------+------------------------------------------- Reporter: brbr | Owner: brbr Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by brbr): * owner: simonmar => brbr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 7 23:48:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jul 2014 23:48:00 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.4289bb9fc38003b51304c4aeba5764f6@haskell.org> #9233: Compiler performance regression ---------------------------------+------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by rwbarton): The following patch reduces compile time for Lennart's program to 15s (compare 9s 7.6.3, 25s 7.8.1, 18s with my previous patch): {{{ diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs index b33eae9..1417ad7 100644 --- a/compiler/types/Coercion.lhs +++ b/compiler/types/Coercion.lhs @@ -1033,6 +1033,7 @@ mkNthCo n (Refl r ty) = ASSERT( ok_tc_app ty n ) Refl r' (tyConAppArgN n ty) where tc = tyConAppTyCon ty r' = nthRole r tc n +mkNthCo n (TyConAppCo _ _ cos) = cos !! n mkNthCo n co = ASSERT( ok_tc_app _ty1 n && ok_tc_app _ty2 n ) NthCo n co where }}} Richard, does this look okay to you (modulo error handling?is it possible that `n >= length cos`?)? I am emboldened by this equation from !OptCoercion {{{ opt_co' env sym mrole (NthCo n (TyConAppCo _ _ cos)) = opt_co env sym mrole (getNth cos n) }}} but cautious due to the comment above it. The simplifier was somehow building up a hugely nested coercion `(Nth:1 (Nth:1 (Nth:1 (... (_R -> _R -> _R -> ... -> _R -> Sym (Identity.NTCo:Identity[0] _R))...))))`. After this patch, the slowdown from 7.6 to 7.8 on Lennart's program is in line with what I see on other modules. There is still a signification regression overall, but this program was particularly bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 05:25:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 05:25:32 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.2026b15040cdf74d14aef24778fe820d@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by juhpetersen): If we don't care too much about 7.8.2, is there anything more to do here for 7.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 09:42:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 09:42:42 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.bdb1926f068f70d7789e2edfebd2f5ce@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): See also: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 10:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 10:22:47 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess Message-ID: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- The attached Haskell program is a stress test for `forkProcess`. It starts 100 child processes, each of which do a single, safe, FFI call, after which the main process waits for all child processes to terminate. I compile the test with {{{ # gcc -c -o TestForkProcessC.o -g TestForkProcessC.c # ghc -debug -threaded -fforce-recomp -Wall TestForkProcess.hs TestForkProcessC.o }}} and then start running it until it fails (that is, until one or more of the child processes fail to terminate): {{{ # while ./TestForkProcess +RTS -N1 ; do echo "OK"; done }}} Actually, most of the time this happens pretty quickly (often even on the first call to `TestForkProcess`). Those child processes that do fail to terminate get stuck in an infinite loop in `shutdownCapability`, which looks something like: {{{ void shutdownCapability (Capability *cap, Task *task, rtsBool safe) { nat i; task->cap = cap; for (i = 0; /* i < 50 */; i++) { // ... other conditionals omitted if (cap->suspended_ccalls && safe) { cap->running_task = NULL; RELEASE_LOCK(&cap->lock); // The IO manager thread might have been slow to start up, // so the first attempt to kill it might not have // succeeded. Just in case, try again - the kill message // will only be sent once. ioManagerDie(); yieldThread(); continue; } traceSparkCounters(cap); RELEASE_LOCK(&cap->lock); break; } } }}} (note that I'm only considering the threaded RTS). In the child processes that loop indefinitely this `cap->suspended_ccalls && safe` condition gets triggered time and again. When it does, it gets stuck waiting for a single `InCall`. This `InCall` is created by a call to `newInCall` in `workerStart` -- i.e., it is created on pthread startup. That begs the question where this worker task was created; this I don't know for sure but I am fairly sure that it happens during the initialization of the IO manager. (The initialization sequence of the IO manager involves the creation of 4 tasks before we even get to `main`, so it's bit a hard to navigate.) I have some further evidence that the I/O manager is involved, although not necessarily the cause of the problem. On normal termination, the I/O manager is asked to shutdown by the call to `ioManagerDie` in `shutdownCapability`, shown above. This will send `IO_MANAGER_DIE` (`0xFE`) on the I/O managers "control pipe" (created in `GHC.Event.Thread.startTimerManagerThread`). When the timer manager thread receives this (in `GHC.Event.TimerManager.handleControlEvent`) it calls `shutdownManagers`, which shuts down the IO manager threads by sending them `io_MANAGER_DIE` on their respective pipes. This gets received by `GHC.Event.Manager.handleControlEvent` and the IO manager threads exit. (Note on capitalization: `IO_MANAGER_DIE` is the C symbol; `io_MANAGER_DIE` is the Haskell symbol.) When the child process fails to terminate, the first part of this process still happens. The timer manager thread receives `IO_MANAGER_DIE` and calls `shutdownManagers`. However, now things go wrong, and it seems they go wrong in one of two ways. The very first thing that `shutdownManagers` does is acquire the `ioManagerLock`. Sometimes it gets stuck right there. However, this is not ''always'' the case. Sometimes it does manage to acquire the lock, and I can see it going through the loop and sending the shutdown signal to the IO manager thread (I'm saying "the" because I've exclusively been testing with `-N1`). Either way, in the case that the child process gets stuck, this signal somehow never arrives at the IO manager thread (that is, I have a print statement in `readControlMessage` that prints a message when it receives `IO_MANAGER_DIE`, along with a bit of information where it was called from, and that print statement never triggers). I am not sure where to go from here. Note that I have only been able to reproduce this on OSX/ghc 7.8. I have not been able to reproduce this problem on Linux/7.8 (although there _are_ other problems with `forkProcess` on Linux, which unfortunately are proving even more elusive). The attached stress test ''does'' very often get stuck on Linux/7.4 but of course that's a different I/O manager altogether and is probably an unrelated bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 12:42:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 12:42:46 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.ffdd878da08ad4ae7dbe64f229a5c381@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): I have a working version of this in the `wip/pattern-synonyms` branch. It still needs some finishing (mostly, adding tests). The only difficult part of this work was ensuring that the following works (and is not regarded as a recursive pattern synonym): {{{ pattern P x <- (x:_) where P x = foo [x] foo (P x) = [x, x] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 12:45:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 12:45:11 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.0e890e02df67a955653ca1a507cb21de@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): Now that I am parsing pattern synonym declarations using the pattern parser (using the same trick as used by the data constructor parser), and typechecking a pattern synonym can add deferred bindings, this should at least be somewhat simpler to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 12:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 12:58:41 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.0b2ca96f985f75377d2f7d570764d594@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): The `StdGen` indeed never generates `0`. This follows from the following line in the function `stdNext` (`z'` is the next generated `Int`): {{{#!haskell z' = if z < 1 then z + 2147483562 else z }}} I checked the paper, and this is as intended. The range should be [1, 2147483562]. novadenizen's script also finds these: {{{#!haskell Just 885777925 -- v == 1 Just 2217242596 -- v == 2147483562 }}} Here's a [https://github.com/haskell/random/pull/7 pull request]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 13:00:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 13:00:47 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.77c24487f8e30189a584935a29842d78@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------ Reporter: novadenizen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/random | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * status: new => patch * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 13:06:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 13:06:21 -0000 Subject: [GHC] #4218: System.Random is way too lazy In-Reply-To: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> References: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> Message-ID: <063.a8c211aaabb9461fe518d344713b7803@haskell.org> #4218: System.Random is way too lazy ---------------------------------+----------------------------------------- Reporter: EyalLotem | Owner: rrnewton Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack overflow Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Changes (by thomie): * cc: rrnewton (added) * difficulty: => Unknown * component: Compiler => libraries/random * milestone: 7.6.2 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 13:29:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 13:29:29 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.4adeeddf4df24dbbf7da04febbb7e541@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): The constant folder doesn't actually fold floating points yet. It's a hard thing to do, without blowing up cross compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 14:03:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 14:03:48 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.568906bad3d14fede991275f493b022d@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: 8299 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 17:16:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 17:16:57 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.cd1b9f6b496e6e60906b3a9d40c5768c@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bravit): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 17:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 17:19:01 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd Message-ID: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> #9285: IO manager startup procedure somewhat odd ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Currently the RTS startup procedure for the threaded runtime with a single capability looks something like this: '''1. Capability gets initialized''' {{{ hs_main real_main hs_init_ghc initScheduler initCapabilities }}} '''2. IO Manager is started''' {{{ hs_main real_main hs_init_ghc ioManagerStart }}} '''3. ensureIOManagerIsRunning''' The IO manager of course is mostly written in Haskell, so `ioManagerStart` does {{{ cap = rts_lock(); rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); rts_unlock(cap); }}} '''4. Bound task is created and we start running Haskell code''' Since this is the first call to `rts_lock`, it creates a bound task to correspond to the current OS thread. '''5. Haskell code does a safe FFI call: create worker task 1''' The first safe FFI call that the IO manager makes (ignoring `labelThread`) is to `c_setIOManagerControlFd`. At this point, the bound task gets suspended and we create a worker task. '''6. Worker task 1 starts executing `GHC.Event.Manager.loop`''' The worker tasks gets suspended due to an explicit call to `yield` in `GHC.Event.Manager.step`, at which point the bound task continues execution. It continues and finishes (`ensureIOManagerRunning` completes). The worker task takes over. '''7. Worker task 1 does a safe FFI call to `I.poll`, create new worker task 2''' (This safe call is from `GHC.Event.Manager.step`) '''8. Worker task 2 executes `GHC.Event.TimerManager.loop`, and does safe FFI call to `I.poll`; create worker task 3''' This worker task will remain spare for now. '''9. Start executing the actual main function''' The IO manager calls `rts_unlock`, which verifies if there are any spare workers available; it finds that there are and doesn't start a new one. Then when we start `main` itself of course we go through this `rts_lock, rts_evalIO, rts_unlock` sequence ''again''. This is somewhat confusing, and makes tracing the startup of the code more difficult to interpret. It seems that this could be simpler: only a single `rts_lock` should be necessary, in which we first call `ensureIOManagerIsRunning` and then `main`, followed by a single `rts_unlock`. A similar simplification should be possible in `forkProcess`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 17:46:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 17:46:53 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.33487000bfcaf01cfb4b7d498a9c475d@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by RyanGlScott): * owner: thoughtpolice => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 21:57:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 21:57:21 -0000 Subject: [GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X ( Message-ID: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> #9286: ghc-7.9.20140707 fails testsuite on OS X ( ----------------------------+---------------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X testsuite | Type of failure: Building GHC failed Architecture: x86_64 | Test Case: T5435_dyn_asm T4801 T6048 (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Using ghc straight from the git repository, I just ran sh validate. The ghc that I used to build this new one was from https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as it does not mess with system system files). This is on Yosemite DP3, XCode 6 Beta 3. {{{ OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST 0:45:11 spent to go through 4039 total tests, which gave rise to 15863 test cases, of which 12161 were skipped 28 had missing libraries 3606 expected passes 65 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 22:19:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 22:19:14 -0000 Subject: [GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X ( In-Reply-To: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> References: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> Message-ID: <057.d6e6370d7244c647dec568cfa85395b1@haskell.org> #9286: ghc-7.9.20140707 fails testsuite on OS X ( ----------------------------------------------+---------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | testsuite Type of failure: Building GHC failed | Architecture: x86_64 Test Case: T5435_dyn_asm T4801 T6048 | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Description changed by jrp: Old description: > Using ghc straight from the git repository, I just ran sh validate. The > ghc that I used to build this new one was from > https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as > it does not mess with system system files). > > This is on Yosemite DP3, XCode 6 Beta 3. > > {{{ > OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST > 0:45:11 spent to go through > 4039 total tests, which gave rise to > 15863 test cases, of which > 12161 were skipped > > 28 had missing libraries > 3606 expected passes > 65 expected failures > > 0 caused framework failures > 0 unexpected passes > 3 unexpected failures > > Unexpected failures: > perf/compiler T4801 [stat too good] (normal) > perf/compiler T6048 [stat not good enough] (optasm) > rts T5435_dyn_asm [bad stdout] (normal) > }}} New description: Using ghc straight from the git repository, I just ran sh validate. The ghc that I used to build this new one was from https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as it does not mess with system system files). This is on Yosemite DP3, XCode 6 Beta 3. {{{ OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST 0:45:11 spent to go through 4039 total tests, which gave rise to 15863 test cases, of which 12161 were skipped 28 had missing libraries 3606 expected passes 65 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) rts T5435_dyn_asm [bad stdout] (normal) }}} The first two test seem not to be serious: {{{ cd ./perf/compiler && '/Users/jrp/Projects/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs +RTS -V0 -tT4801.comp.stats --machine- readable -RTS -static >T4801.comp.stderr 2>&1 peak_megabytes_allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected peak_megabytes_allocated: 70 +/-1% Lower bound peak_megabytes_allocated: 69 Upper bound peak_megabytes_allocated: 71 Actual peak_megabytes_allocated: 68 bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected bytes allocated: 464872776 +/-5% Lower bound bytes allocated: 441629137 Upper bound bytes allocated: 488116415 Actual bytes allocated: 417565216 *** unexpected failure for T4801(normal) =====> T3064(normal) 1987 of 4039 [0, 1, 0] }}} {{{ =====> T6048(optasm) 1997 of 4039 [0, 1, 0] cd ./perf/compiler && '/Users/jrp/Projects/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 110646312 +/-10% Lower bound bytes allocated: 99581680 Upper bound bytes allocated: 121710944 Actual bytes allocated: 125434224 *** unexpected failure for T6048(optasm) }}} Not sure about T5435_dyn_asm {{{ T5435_dyn_asm failed with ['modInitFunc1', 'modInitFunc2', 'success'], see all.T for details }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 8 22:50:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jul 2014 22:50:02 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.8a7b62ce5c70594f6c0698625f2f0f7c@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 01:42:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 01:42:12 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.a3eb6f9d39ac1b8bc09c0d12153f568c@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by RyanGlScott): Here is a minimal plugin example which triggers the error (the full code is [https://github.com/RyanGlScott/ghc-plugin-test here]): {{{ module TestPlugin (plugin) where import CoreMonad import GhcPlugins import HscTypes import Outputable plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ todo = do reinitializeGlobals putMsgS "Hello!" return $ CoreDoPluginPass "Say module name" pass : todo pass :: ModGuts -> CoreM ModGuts pass guts = do dflags <- getDynFlags putMsgS "Will this crash on Windows?" putMsgS $ showPpr dflags (mg_module guts) putMsgS "Nope" return guts }}} Here is the output: {{{ $ ghc Main.hs -fplugin=TestPlugin [1 of 1] Compiling Main ( Main.hs, Main.o ) [TestPlugin changed] Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package Win32-2.3.0.2 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.1.3 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.1 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.8.2 ... linking ... done. Loading package ghc-plugin-test-0.1.0.0 ... linking ... done. Hello! Will this crash on Windows? ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 04:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 04:26:32 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.06f42b408cccf98fc4aee653de2183d1@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by AndreasVoellmy): I've verified that the test case triggers the bug in my environment (OS X 10.9.4 with GHC HEAD) as well. FWIW, it seems that just sampling the process (i.e. using "/usr/bin/sample" in OS X) causes the stuck process to finish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 09:43:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 09:43:21 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.e6fde3d675323002e70a9f54f60e3268@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Ah, yes, perhaps I should have mentioned -- I tried connecting `lldb` to the stuck process and that too was enough to nudge it to completion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 10:59:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 10:59:03 -0000 Subject: [GHC] #9287: changed dependency generation Message-ID: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> #9287: changed dependency generation ------------------------------------+-------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- "ghc -M" for ghc-7.8.x changed in that an error occurs: {{{ You must specify at least one -dep-suffix }}} By chance (#8746) I found that {{{ ghc -M -dep-suffix "" B.hs }}} works, but only for the new ghc-7.8.x. For module B importing module A the following dependencies are generated: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o : A.hs B.o : B.hs B.o : A.hi # DO NOT DELETE: End of Haskell dependencies }}} The same command used with ghc-7.6.x produces wrong dependencies: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A._o : A.hs B.o B._o : B.hs B.o : A.hi B._o : A._hi # DO NOT DELETE: End of Haskell dependencies }}} Obviously, only for dynamic linking a dep-suffix should be needed. However for ghc-7.6. this must be "dyn" and for ghc-7.8.x this must "dyn_" plus the empty suffix! {{{ ghc-7.6.3 -M -dep-suffix dyn B.hs ghc-7.8.2 -M -dep-suffix dyn_ -dep-suffix "" B.hs }}} Both calls produce: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A.dyn_o : A.hs B.o B.dyn_o : B.hs B.o : A.hi B.dyn_o : A.dyn_hi # DO NOT DELETE: End of Haskell dependencies }}} The changed behavior is not documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/separate- compilation.html#makefile-dependencies The (accidental?) change should also be documented in the release notes! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 15:40:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 15:40:57 -0000 Subject: [GHC] #9288: Type class overlapping instances check doesn't understand type equality Message-ID: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> #9288: Type class overlapping instances check doesn't understand type equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Here is a sample program which we'd expect to give an overlapping instances error, but does not: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module Foo where type family F a :: * type instance F Bool = Int type instance F Int = Bool class C a where instance (F Bool ~ a) => C a where instance C Int where }}} Fortunately, GHC does notice when you actually try to use the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 20:40:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 20:40:30 -0000 Subject: [GHC] #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) Message-ID: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- I was talking with Reid Barton, and he pointed out that having a primop with type {{{ anyToAddr# :: (#a#)-> Addr# }}} would help with a lot of performance hacking. One use case would be running prefetch on lifted values without evaluating them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 21:14:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 21:14:19 -0000 Subject: [GHC] #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) In-Reply-To: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> References: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> Message-ID: <060.6a4c102bc3223246a07758209da78ccc@haskell.org> #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): In particular, you could use it to prefetch a heap object without making any assumptions about the representation of pointers to heap objects (imagine if we used a pointer tagging scheme that used bits 48-62 on x86_64, or compressed pointers). Not sure off-hand what else it would be useful for given that the GC could move the object after we get the `Addr#`; maybe it makes more sense to add a variant of prefetch `a -> Int# -> (# a #)` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 21:36:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 21:36:16 -0000 Subject: [GHC] #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) In-Reply-To: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> References: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> Message-ID: <060.3c43626ce122791cc87fb0534c9d0faa@haskell.org> #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Thats a good idea! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 9 22:08:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jul 2014 22:08:58 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.d9de4c8d8f712a0ed456becda542fcb3@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------+------------------------------------ Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by Henk-Jan): * cc: hvr (added) Comment: The problem still exists with GHC 7.8.2, compiled with DYNAMIC_GHC_PROGRAMS=YES. This is tested on Windows 8.1 (64-bit) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 00:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 00:20:52 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.724d1e854b224aee4883eb62de7c71d0@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"bd5f3ef6585640f762d96426bb041d79a5038e8e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bd5f3ef6585640f762d96426bb041d79a5038e8e" rts: Fix #9003 with an annoying hack The TL;DR is that by adding this, we can distinguish GHC 7.8.3 from 7.8.2, which had a buggy implementation. See the ticket for details. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 00:22:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 00:22:37 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.b7e986afd68b43b05b466432770d0270@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: @jberthold - this is done. 7.8.3 and HEAD now include a `EVENT_HACK_BUG_T9003` event that you should be able to use. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 02:23:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 02:23:52 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.c88890a981f93bc6315030a3cc613aa1@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by AndreasVoellmy): I just verified that the bug occurs even if you remove the call to `safeFfiFunction 2` in main, and replace it with `return ()`. It takes longer to trigger the problem, but it does still occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 03:05:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 03:05:50 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.9119563a01874b314f10bd5bd9cb6be9@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by cactus): * status: new => patch Comment: Pushed `576f461` to `wip/pattern-synonyms`, please review for `HEAD`. It validates and has a test case for bidirectional pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 03:11:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 03:11:35 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.a0041ea196d3d6e9793438ac2a632116@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by cactus): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 03:36:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 03:36:57 -0000 Subject: [GHC] #9290: The job a whole tight will be Message-ID: <054.58aa3eb67a08bfbd2e11e9418d516f81@haskell.org> #9290: The job a whole tight will be ------------------------------------+------------------------------------- Reporter: herbertlawrence | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Horsepower XXL | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- You really have a great and rebuilding you know by you think I think there I'd get there I think character is an American as apple pie we live in a society today you got it and he in reality shows Madonna is making out with Britney Spears randy is a candle and hit you worried about steroids kids like you got to you made playing video games the current tampering [http://slioswim.com/ Horsepower XXL] that more influence in my opinion this can lead to ever be in Barry Bonds hit a homerun if there's a big difference between him taking them you don't need Paralympics a couple years as opposed to have grown man looking to perform better and better level in sports and we're thrilled maker known as I mean he?s the poster boy hysterical think the modem we heard it look at me like I did came I conquered a kickass that more biography says he was born in with 15 16 hey he won at the University nineteen-years-old 19 get to see what it looks like when hews 19 you think it was God given to next time you think that maybe people to performance-enhancing white people idolize these guys went into rock band body blow the movies on whether at all when you get to meet them and mandate a webcam a good day never at her what they appear to be thing I do you think in public like this got the middle finger on the table like this never look at the end what you get what you think and what they want you to see everybody idolized Schwarzenegger going up everybody put my hand want to lightweights in the end up. http://slioswim.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 04:36:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 04:36:23 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.a7f25041f9f85ce417069d4be7b8fea6@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by AndreasVoellmy): I haven't yet nailed it down, but here is my current guess as to what is happening when it gets stuck... The child process's IO manager thread is blocked in the foreign call on kevent indefinitely (as you describe). The intention is that `ioManagerDie()` writes to the control pipe that the kevent is subscribed to, and this write will cause the kevent call to return from its foreign call. It seems that the RTS has a file descriptor for the write end of the pipe (set by the call to `c_setIOManagerControlFd` in `GHC.Event.Control`) and so does the event manager on the HS side. I suspect that these get out of sync after the fork and exec; i.e. `ioManagerDie()` writes to some file descriptor that no longer corresponds to the write end of the pipe that kevent is waiting on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 05:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 05:00:23 -0000 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> References: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> Message-ID: <061.a13569ec4e5578dc372c1abd9a5f1329@haskell.org> #284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ? Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ydewit): There seems to be two areas that need to be fixed to support relocatable installs: the shell wrappers and the .conf files. Both of these set of files have absolute paths. Regarding the shell wrappers (e.g. $GHC_HOME/bin/{ghc,ghc- pkg,ghci,runghc,runhaskell}), we could simply use a slightly different scheme. For instance, an alternative for the ghc wrapper: {{{ #!/bin/sh GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) exedir="${GHC_HOME}/lib/ghc-7.8.2/bin" exeprog="ghc-stage2" executablename="$exedir/$exeprog" datadir="${GHC_HOME}/lib" bindir="${GHC_HOME}/bin" topdir="${GHC_HOME}" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" ${1+"$@"} }}} The critical piece is {{{ GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) }}} since it needs to work for all supported platforms. Other than that, it is pretty straight-forward. I see that there is support for a {{{RelocatableBuild}}} variable in config.mk, but it is turned on only on Windows: {{{ # On Windows we normally want to make a relocatable bindist, to we # ignore flags like libdir ifeq "$(Windows_Host)" "YES" RelocatableBuild = YES else RelocatableBuild = NO endif }}} So it seems that we have two different layouts: one for Windows and one for everything else: {{{ exec_prefix = ${prefix} bindir = ${exec_prefix}/bin datadir = ${datarootdir} libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${datarootdir}/man docdir = ${datarootdir}/doc/${PACKAGE_TARNAME} $(eval $(call set_default,docdir,$${datarootdir}/doc/ghc)) htmldir = ${docdir} dvidir = ${docdir} pdfdir = ${docdir} psdir = ${docdir} $(eval $(call set_default,htmldir,$${docdir})) $(eval $(call set_default,dvidir,$${docdir})) $(eval $(call set_default,pdfdir,$${docdir})) $(eval $(call set_default,psdir,$${docdir})) ifeq "$(RelocatableBuild)" "YES" # Hack: our directory layouts tend to be different on Windows, so # hack around configure's bogus assumptions here. datarootdir = $(prefix) datadir = $(prefix)/lib libdir = $(prefix)/lib docdir = $(prefix)/doc htmldir = $(docdir) dvidir = $(docdir) pdfdir = $(docdir) psdir = $(docdir) ghclibdir = $(libdir) ghcdocdir = $(datarootdir)/doc else # Unix: override libdir and datadir to put ghc-specific stuff in # a subdirectory with the version number included. # # datadir is set to libdir here as GHC needs package.conf and unlit # to be in the same place (and things like ghc-pkg need to agree on # where package.conf is, so we just set it globally). # ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) ghcdocdir = $(datarootdir)/doc/ghc endif ghclibexecdir = $(ghclibdir) topdir = $(ghclibdir) ghcheaderdir = $(ghclibdir)/include }}} Why two layouts? I also see that the non-windows layout is accounting for cross compilation, which is doesn't seem supported in the Windows layout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 05:00:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 05:00:51 -0000 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> References: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> Message-ID: <061.1fc389e0d540cbd8075d7c2824ba14a4@haskell.org> #284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ? Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ydewit): * cc: ydewit@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 05:36:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 05:36:47 -0000 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> References: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> Message-ID: <061.5f96a0c10d8f654314b798331c24cad6@haskell.org> #284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ? Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I don't think relocating is quite that simple. Eg On OS X, dylibs can't use relative paths (last I checked), so relocating dylibs requires an invocation of the install-name-tool to fixup the paths! (my recollection could be totally wrong mind you) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 06:33:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 06:33:05 -0000 Subject: [GHC] #9291: Best Muscle building supplement Message-ID: <054.29fb5ee3ff90588dc05d8712f2aec4e3@haskell.org> #9291: Best Muscle building supplement ------------------------------------+------------------------------------- Reporter: herbertlawrence | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Horsepower XXL | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A improvement passim up the ablaze up see you afterwards alright why potshots it may become bacteria hey it's Kyle Leon here I fabricated the abbreviate presentation for you because I wish to betrayal the three biggest bodybuilding Liza mistakes there in actuality authoritative it impossible for you to anatomy apparent muscle quickly and are amenable for what you ?relooking the aforementioned anniversary afterwards week you will be abashed but you will learn the accuracy about what is captivation you back from accepting the angular beef you deserve and by the end of this presentation you also apprentice in actuality how to breach through your muscle-building Pluto and you'll be on your way to packing on slabs ripped angular muscle without any fat now that sounds great but if you're annihilation like me [http://slioswim.com/ Horsepower XXL] you're going to wish quick safe and permanent results without accepting to await on things like dangerous steroids pills powders potions or even crazy hours in the gym I'm going to accord you the band-aid that will do just that I'm traveling to accord you the band-aid that abandoned use that accustomed me to overcome my genetics lose my top academy appellation the lanky Leo and become a supplement sponsored athlete by packing on and befitting 21pounds a in actuality muscle in just over a week's afterwards advertise aft this band-aid has landed me on magazine covers a supplement sponsorship and as ultimately afflicted my action that?s why I'm administration this admonition with you today I want to accord you. http://slioswim.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 10:40:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 10:40:07 -0000 Subject: [GHC] #9290: ghci panic on ':type' Message-ID: <046.3132cdca011060ed77a342c35c473438@haskell.org> #9290: ghci panic on ':type' ----------------------------------+------------------------------------- Reporter: raichoo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Hi, I just made ghci panic by doing the following: {{{ ?? let inf = 1 + inf ?? :sprint inf inf = _ ?? :print inf inf = (_t1::Num a => a) ?? :t _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a{tv au3} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Kind regards, raichoo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 11:48:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 11:48:15 -0000 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> References: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> Message-ID: <061.6a0530af274ddf7778c960f2ef668f69@haskell.org> #284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ? Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ydewit): This is what I see with {{{otool -L}}}: {{{ /t/g/l/g/array-0.5.0.0 ??? otool -L libHSarray-0.5.0.0-ghc7.9.20140709.dylib libHSarray-0.5.0.0-ghc7.9.20140709.dylib: @rpath/libHSarray-0.5.0.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) @rpath/libHSbase-4.7.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSinteger-gmp-0.5.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc-prim-0.3.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0) }}} My understanding is that {{{@rpath}}}, which seems to be a feature added in 10.5, means this dylib can be relocated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 12:47:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 12:47:58 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.4e576d8b78e898038f8bb0bbd10773eb@haskell.org> #7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Comment (by jstolarek): I have made some progress on this one today. I'm able to compile {{{ test :: Arrow a => a i i test = proc n -> do returnA -< n }}} using the new desugaring, which was not possible earlier. But I'm still stuck on this: {{{ test :: Arrow a => a i i test = proc n -> do returnA -< n returnA -< n }}} ie. desugaring of `thenA` although now I have gathered more information. With my new implementation the code above desugars to: {{{ (>>>) @ i @ (i, ()) @ i (arr @ i @ (i, ()) (\ (n :: i) -> (n, ()))) (thenA @ arrow @ i @ (GHC.Prim.Any *) @ (GHC.Prim.Any *) @ i $dArrow_auX ((>>>) @ (i, ()) @ i @ i (arr @ (i, ()) @ i (\ (ds2 :: (i, ())) -> case ds2 of _ { (ds4, ds5) -> ds4 })) (Control.Arrow.returnA @ arrow @ i $dArrow_auX)) ((>>>) @ (i, ()) @ i @ i (arr @ (i, ()) @ i (\ (ds2 :: (i, ())) -> case ds2 of _ { (ds4, ds5) -> ds4 })) (Control.Arrow.returnA @ arrow @ i $dArrow_auX))) }}} This looks correct except for the two `(GHC.Prim.Any *)` type parameters to `thenA`. One corresponds to the type of the stack, the other to result of first command (`b` in the type signature `a (e,s) b -> a (e,s) c -> a (e,s) c`). `thenA` should be polymorphic in these, but it seems that during typechecking I need to instantiate `s` and `b` to concrete values. I noticed that desugaring of `cmd` stored in the `BodyStmt` always passes `()` as the type of the stack. If this is correct then there's only the problem of what to do with `b`. Help needed here becuase I have no idea how to figure out the type of `b` from within `tcArrDoStmt`. Ross, I also tried to implement desugaring of `bind`. When generating the desugared Core for `cmd 'bind' \ p -> do { ss }` I have problem with the `\p ->` part. So, given the desugared `do { ss }`, `cmd` and the `bind` operator how should the generated command lambda look like? I'm still at a loss to undestand how to explicitly manipulate the stack from within Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 13:29:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 13:29:40 -0000 Subject: [GHC] #9290: ghci panic on ':type' In-Reply-To: <046.3132cdca011060ed77a342c35c473438@haskell.org> References: <046.3132cdca011060ed77a342c35c473438@haskell.org> Message-ID: <061.fb48732843e152854197be5133293d36@haskell.org> #9290: ghci panic on ':type' -------------------------------------+---------------------------------- Reporter: raichoo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #9046. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 13:49:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 13:49:15 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes Message-ID: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Consider this test case: {{{ module Main (main) where fun :: Either Int String -> Either String String fun x = case x of Left int -> Left (show int) Right str -> Right str {-# NOINLINE fun #-} main :: IO () main = do l <- getLine print $ fun (Right l) }}} The core we get for fun looks like: {{{ Main.fun [InlPrag=NOINLINE] :: Data.Either.Either GHC.Types.Int GHC.Base.String -> Data.Either.Either GHC.Base.String GHC.Base.String [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ] Main.fun = \ (x_aur :: Data.Either.Either GHC.Types.Int GHC.Base.String) -> case x_aur of _ [Occ=Dead] { Data.Either.Left int_aus -> Data.Either.Left @ GHC.Base.String @ GHC.Base.String (GHC.Show.$fShowInt_$cshow int_aus); Data.Either.Right str_aCG -> Data.Either.Right @ GHC.Base.String @ GHC.Base.String str_aCG } }}} There would be less allocations and probably perform better if we just coerced `x` into the new type. Because the coercion is common code, this also means that if hypothetically some other sum type which had 15 constructors, and only 3 had subtle type changes, 12 of the case branches could be CSE'd into the single coerce greatly reducing code generated and also hinting the inliner better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 13:53:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 13:53:49 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.9c7b02da854e1624700589bbc043f849@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Clarification, the ticket is talking about performing the coercion in the `Right ->` branch, where the reconstruction *seems* pointless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 14:04:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 14:04:47 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.79af2e49b02c0d7f013a732011026fe8@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by nomeata): Are Core?s coercions expressible enough for this? I don?t think so. So one would have to resort to `unsafeCoerce` here, which wouldn?t be nice. Or this can be done at the STG stage, but then we might miss further optimizations. Tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 14:17:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 14:17:08 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.6fdc2a50cc63dbf523b5c8bcd4360db2@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Why would the compiler inserting unsafeCoerce be bad? I would have thought that's something the compiler should be able to do a lot of, given we have such a better type system than other languages which can't prove it's safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 14:20:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 14:20:20 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.478caf8bc7a47e3f8903f9793c893970@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by nomeata): The type system of Core is actually _better_ than that of Haskell (for some value of better). And having a typed intermediate language has many benefits, e.g. it is easier to spot bugs in the core-to-core transformations. An example for what happens when you use unsafeCoerce, even internally: GeneralizedNewtypeDeriving used to be implemented this way, and together with Type Families or GADTS it was suddenly possible to crash a Haskell program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 15:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 15:41:38 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.025017f3da256feb3bcc43c2c5832a82@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by goldfire): The way that we have proved Haskell's type system safe is precisely because Core is proved safe. Haskell itself, from a formal standpoint, is defined solely by its transformation into Core. If the compiler used `unsafeCoerce` internally, then any claims of safety would be bogus. What is seems you're asking for is a strange new beast in Core... something of a dependently-typed coercion, that requires a proof that the term it is coercing is built with the constructors whose type is not changing. I don't think this is impossible, but I don't envy the person that does the proof! This is somewhat disappointing, because I agree that it would be great to have this optimization! Perhaps others see the theory differently... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 15:45:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 15:45:48 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.2a2ac2b9aa2099a54c947c9a4946ef2d@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): What about packages that include "cbits" where the calling convention (or just semantics) of the C function changes from one version to the next? Won't the linker complain or, worse, just pick one? I guess with dynamic linking it might work. Admittedly, it could already happen that two unrelated packages use clashing names for their incompatible "cbits" C functions, but it seems rather more likely to occur between one version of a package and the next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 15:53:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 15:53:26 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.f27f22aedde4f40bb5a7bdfb125a6694@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): OK, the situation for internal cbits is different. While an external library is shared, internal C code is not shared. I think this would only work if the functions defined in the cbits are not exported outside of the library boundary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 16:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 16:11:43 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.d59df9b077995ab01de966f3fc1ef5df@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by augustss): You can check if the host and the target have the same kind of FP (easy if host==target) and only constant fold under that condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 16:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 16:17:14 -0000 Subject: [GHC] #9292: Race condition when multiple threads wait for a process Message-ID: <047.29e34a11a2b337754c8213a9e3820c54@haskell.org> #9292: Race condition when multiple threads wait for a process -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | 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: | -------------------------------------+------------------------------------- Consider the following code: {{{ import System.Process import Control.Concurrent.Async main :: IO () main = do (_, _, _, ph) <- createProcess $ shell "sleep 1" let helper i = do ec <- waitForProcess ph print (i :: Int, ec) ((), ()) <- concurrently (helper 1) (helper 2) return () }}} If I compile with the single threaded runtime, I get the output {{{ (2,ExitSuccess) (1,ExitSuccess) }}} But when compiling with the multithreaded runtime, I get: {{{ bin: waitForProcess: does not exist (No child processes) }}} If you need to wait for a process from multiple threads, you can do so now by having a dedicated wait thread which writes to an MVar or TMVar, but the current default behavior can be surprising. I discussed this in a [http://www.yesodweb.com/blog/2014/07/rfc-new-data- conduit-process blog post], and there was some [http://www.reddit.com/r/haskell/comments/2abmwu/rfc_new_dataconduitprocess/cithh69 conversation on Reddit]. At the least, I think we need better documentation, but if there's a better solution, that would be best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 16:21:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 16:21:40 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.335aeec78cd3a90cd2c8c2d0648240e0@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by rwbarton): I think the lens package uses this pattern extensively, or at least something closely related. In discussion with "napping" on IRC the idea arose to extend Core-level `case` with the power to generalize the type of its scrutinee. For example, if `x :: Either Int String`, then (using a syntax inspired by as- patterns, and omitting some noisy details) {{{ case x of _ { xLeft@(Left int) -> {- here xLeft :: Either Int b (we don't use it) -} Left @ String @ String (show @ Int int) xRight@(Right str) -> {- here xRight :: Either a String -} xRight @ String } }}} The appropriate amount of type generalization would depend on the type variables that appear in the fields of the constructor that was matched, after translating GADT constructors into type equality constraints. For example given the type `data X a b where MkX :: b -> X Int b`, if we match `x :: X Int Char` with `MkX Char`, we cannot generalize the type of `x` to `X a Char`, since the translated type of `MkX` is `MkX :: (a ~ Int) => b -> X a b` which does mention `a` on the left-hand side (in a constraint). This is all rather similar to role inference for data types, I imagine, except done on a per-constructor basis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 16:39:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 16:39:10 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.b8472d935d279ebe852d6ccad65323d8@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): yeah, i'm not concerned with even doing optimization yet, just making sure all the suitable primitives are exposed :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 16:39:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 16:39:24 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.a59bf8b9e2e4a57669ef17359d713ff2@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by goldfire): That's an interesting idea, perhaps somewhat saner than dependently-typed coercions. But, proving such a thing type-safe would be quite a bear, I think. It seems to hinge on parametricity, which is not yet proven for Haskell or Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:04:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:04:27 -0000 Subject: [GHC] #9288: Type class overlapping instances check doesn't understand type equality In-Reply-To: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> References: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> Message-ID: <060.10cb97046f5b3e8752f7fe7124b3519c@haskell.org> #9288: Type class overlapping instances check doesn't understand type equality ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by aavogt): A simpler example where ghc-7.8.2 doesn't detect overlapping instances until they are used {{{ {-# LANGUAGE FlexibleInstances #-} class C a where c :: a instance C a where c = undefined instance C Int where c = 2 -- ghc doesn't complain about overlapping instances -- unless you uncomment c1 -- c1 = c :: Int c2 = c :: Double }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:10:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:10:08 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.6ad71fe2c4a1a44d4317de04f5cb9b42@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9282 -------------------------------------+------------------------------------ Changes (by rwbarton): * related: => #9282 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:10:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:10:45 -0000 Subject: [GHC] #9288: Type class overlapping instances check doesn't understand type equality In-Reply-To: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> References: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> Message-ID: <060.7b998df2962582be03147ecd5079931e@haskell.org> #9288: Type class overlapping instances check doesn't understand type equality ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by aavogt): * cc: vogt.adam@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:12:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:12:20 -0000 Subject: [GHC] #9282: GHCi ignores .dyn_o files In-Reply-To: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> References: <045.e365b99de4325bc6a49457e57c4bf672@haskell.org> Message-ID: <060.06c0a242f6ea24c15700c4c758ce10a4@haskell.org> #9282: GHCi ignores .dyn_o files -------------------------------------+----------------------------------- Reporter: mietek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: duplicate | Keywords: dynamic linking Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: See #8736. As a workaround you can use `-dynamic`, ''not'' `-dynamic-too`. That will create dynamic-style `.o` and `.hi` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:26:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:26:27 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.f4bba20e28147e1e18b0f2d2998bbdfa@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): Actually it looks like `forkProcess` is already simpler. It only calls `ioManagerStartCap(&cap);` because it's already in the context of holding the capability. So in summary, we're suggesting that in the rts startup we should be using `ioManagerStartCap(&cap);` in a context where we already hold the initial cap and before we run main. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:33:53 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.d5f1092ce2e122f351599c20bdd6b25e@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): So I suppose I'm suggesting something like this: {{{ diff --git a/rts/RtsStartup.c b/rts/RtsStartup.c index 8e7e11d..38435d8 100644 --- a/rts/RtsStartup.c +++ b/rts/RtsStartup.c @@ -258,11 +258,6 @@ hs_init_ghc(int *argc, char **argv[], RtsConfig rts_config) // ToDo: make this work in the presence of multiple hs_add_root()s. initProfiling2(); - // ditto. -#if defined(THREADED_RTS) - ioManagerStart(); -#endif - /* Record initialization times */ stat_endInit(); }}} {{{ diff --git a/rts/RtsMain.c b/rts/RtsMain.c index df63716..68b2c79 100644 --- a/rts/RtsMain.c +++ b/rts/RtsMain.c @@ -60,6 +60,9 @@ static void real_main(void) /* ToDo: want to start with a larger stack size */ { Capability *cap = rts_lock(); +#if defined(THREADED_RTS) + ioManagerStartCap(&cap); +#endif rts_evalLazyIO(&cap,progmain_closure, NULL); status = rts_getSchedStatus(cap); rts_unlock(cap); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 17:54:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 17:54:59 -0000 Subject: [GHC] #8338: Incoherent instances without -XIncoherentInstances In-Reply-To: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> References: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> Message-ID: <062.da1da5ea8e900fb3ca3f654528ca0678@haskell.org> #8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2356 -------------------------------------+------------------------------------ Changes (by rwbarton): * related: => #2356 Comment: GHC has allowed multiple instances for the same type and class to coexist in a single program for a long time without any fancy language features. See discussion at #2356. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 18:08:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 18:08:44 -0000 Subject: [GHC] #9285: IO manager startup procedure somewhat odd In-Reply-To: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> References: <044.a7ab40532a3a20a4ca082f731e68f5e6@haskell.org> Message-ID: <059.a1c6efc7514fb9a90dd8e2ceb1c3c6e8@haskell.org> #9285: IO manager startup procedure somewhat odd -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 18:16:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 18:16:38 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.c8801089ab357de6019ad0edac661e8b@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by heisenbug): * cc: ggreif@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 19:27:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 19:27:16 -0000 Subject: [GHC] #4218: System.Random is way too lazy In-Reply-To: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> References: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> Message-ID: <063.176f1d9ffac16575000b929a838ea151@haskell.org> #4218: System.Random is way too lazy ---------------------------------+----------------------------------------- Reporter: EyalLotem | Owner: rrnewton Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack overflow Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Changes (by thomie): * status: new => patch Comment: https://github.com/haskell/random/pull/8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 20:37:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 20:37:57 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.2c58db8ba9cf9e9fb2f7a218cdb1e800@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): @rwbarton, does that still make it simple for the CSE to eliminate extra branches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 20:40:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 20:40:25 -0000 Subject: [GHC] #7936: newStdGen leaks memory when result is not used In-Reply-To: <050.05a3639c415d290213c91c5af3af641f@haskell.org> References: <050.05a3639c415d290213c91c5af3af641f@haskell.org> Message-ID: <065.d7b837e67a00834fec43230accbd6c57@haskell.org> #7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------ Reporter: ryantrinkle | Owner: rrnewton Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thomie): * cc: rrnewton (added) * status: new => patch Comment: ?https://github.com/haskell/random/pull/8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 21:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 21:13:37 -0000 Subject: [GHC] #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. In-Reply-To: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> References: <043.6a1fd2f460bf30afe6ec4f49d43bfb3e@haskell.org> Message-ID: <058.18e3dbbd81070c2c0495174eef08f0d3@haskell.org> #9271: Avoid unnecessary clock_gettime() syscalls in GC stats. -------------------------------+------------------------------------------- Reporter: brbr | Owner: brbr Type: task | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by brbr): * status: new => closed * resolution: => fixed Comment: Merged in: https://phabricator.haskell.org/rGHC3c9fc104337a142fe4f375d30d7a6b81d55a70c1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 10 23:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jul 2014 23:41:09 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" Message-ID: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------+------------------------------------------------- Reporter: | Owner: jfeltz | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: None/Unknown Keywords: | Test Case: :set -XCPP followed by Architecture: x86 | :unset -XCPP Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Any language extension tried appears to not work with :unset. To make matters worse, :unset expands to a number of options, misleading the user into thinking that it should (if that is the case). I eventually had to ask someone on IRC #haskell, leading to the :set -XNoLanguageExtension trick to do what I needed. A fix to :unset is suggested, or removing the misleading/non-working command. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 03:11:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 03:11:37 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module Message-ID: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> #9294: More exports and documentation for GHC API Parser Module ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- I would like to be able to use the GHC API for parsing. Right now this is in the Parser and Lexer modules: Parser: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html Lexer: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html GHC currently exposes only a few parsers here. I'd like to make a few modifications: 1. Expose a few more parsers than currently are exposed in the Parser module. In particular, I'd like import statements, type signatures, declarations, and expressions, at least, in addition to what's already there. 2. Add some Haddock documentation to the top of the Parser module describing how to use it, since the types themselves are pretty opaque here. 3. Export a clean and self-contained parsing API from the GHC module. See minor discussion here: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 03:55:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 03:55:52 -0000 Subject: [GHC] #9295: Eliminating all extra fats from my body Message-ID: <051.c0732681359b53c35293e0d42db76f03@haskell.org> #9295: Eliminating all extra fats from my body -------------------------------------------------+------------------------- Reporter: mehraangupta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: fresh bloodless class kernel | 7.8.2 take away | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- Your system and you use more weight while exercising in the morning know this is sometimes debated you know oh you can also lose your muscle mass but you know generally if you're if you?re eating light furious that was a little bit muscle mass you think your protein intake up though so definitely tracked not here what do you know there I'm sorry milt on is acting crazy his rambunctious today so definitely keep your protein that something obviously for and also help you maintain your muscle mass and I would suggest using chicken breast mean white me and green turkey roast turkey an or fish now fish is an always [http://purewhitekidneybeanextractfacts.com/ fresh bloodless class kernel take away] the cheapest and love what I?m doing right now is a grilled salmon per se I mean that?s great that's a little more on the pricey side so if you?re on a budget go for Latvia on how a bit wearable whitefish and dozens don't have chief issue reverse it is a really good for those of you who are starting off but the mean things are just read that lemon water in the morning to metabolism going E a clean break this I've been trying to stay away from a lot of meets lately with the exception of adding a chicken breast my solid and for lunch for the past 3-4 weeks have any solid every day and you would be surprised at how doing those things can be and ait?s really been helping you lose weight extremist on it you mean mister a quick okay so I don't you guys we not see difference but I definitely deal so it's been hoping he told a lot but when I'm were on the stamps in roles in the mix it's not helping like a sec at me that processed be and these are just some quick simple tips and a half for you and another thing you know in regards to motivation is look at pictures and what do youwanna look like don't look at them. http://purewhitekidneybeanextractfacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 04:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 04:24:55 -0000 Subject: [GHC] #9296: This weight losing solution is helpful in reducing Your huge and bulky figure Message-ID: <051.f59f9425001292505081b50bb767e40e@haskell.org> #9296: This weight losing solution is helpful in reducing Your huge and bulky figure -------------------------------------------------+------------------------- Reporter: mehraangupta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: fresh bloodless class kernel | 7.8.2 take away | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- The liver does not regulate fat metabolism efficiently weight gain tends to occur around the belly area an effort to bring abdomen also known as a potbelly will develop another side a bit on healthy liver can be a row a fact under the operatic get the liver filters not function correctly can remove the small fact lobules Kyle microns that circulate in the bloodstream these extra Kyle microns can build up another organs and fatty deposits under the scan which can lead to cellulite which tends to be found in your butt fish arms and belly it can be very difficult to lose this abdominal fat until the liver function [http://purewhitekidneybeanextractfacts.com/ fresh bloodless class kernel take away] as improved that's one of the major reasons that the older we get the fatter we get so but I basically trying to say is this when your liver is caught up with junk it will be difficult to lose weight no matter how much dieting and exercise you down ever wonder why whenever you would diet and then stop you gain the weight right back but clean out your liver properly and turn it right back into the fat burning metabolism boosting organ that it can be imagine starting a good weight loss program but the healthy liver that?s regularly bring fact for you 24 hours away seven days a week even while you sleep the key here is to get your body is healthy as possible before beginning a proper weight loss program I believe it starting weight loss program with how cleansing and purifying. http://purewhitekidneybeanextractfacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 06:33:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 06:33:55 -0000 Subject: [GHC] #9297: Weight losing product gives you long lasting results without any effort Message-ID: <051.81bfd7c4862dff37b3a60e946195a05b@haskell.org> #9297: Weight losing product gives you long lasting results without any effort -------------------------------------------------+------------------------- Reporter: mehraangupta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: fresh bloodless class kernel | 7.8.2 take away | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- Again thanks for watching minds jotting within sampan lost but she said the life listed I'm Corrine Rachel I'm a certified health coach in today I want to give you can easy ways to lose weight so want to start out by asking you a question do you consume products like these that have the word diet or have the word light on that I'll do you think that they?re hoping you lose weight today I'm going to give you can easy core optical tips that will help you lose weight I'm going to tell you the truth about products like peas at the root up weight loss live hunger and my first it is to learn how to control your hunger so that hunger stop controlling you it'sgonna be a lot easier to live our lives before just not feeling hungry all the time then it will constantly hungry and we?re constantly trying to resist eating its cell I have a couple videos the talk about controlling hunger the primary thing Hills eating whole natural since [http://purewhitekidneybeanextractfacts.com/ clear milky variety nugget obtain] as long as you're eating a diet up processed foods you are always going to feel hungry never going to really feel satisfied eating lot of refined carbohydrates and sugar is also going to contribute to you never really being able to satisfy your hunger but once you can actually satisfy your hunger and achieve that feeling up being whole that?s going to be the first step to really losing weight the calories but we drink are perhaps the most insidious calories that we consume because we don't associate sugary drinks with weight gain the way we associate candy bars and hamburgers was waiting but you can just imagine that big goal on your thighs because sugary drinks do turn in the fact and do 'cause weakening so game of sugary drinks is. http://purewhitekidneybeanextractfacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 07:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 07:13:19 -0000 Subject: [GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" In-Reply-To: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> References: <045.daa7d347a465945558e9c7e97d33ff13@haskell.org> Message-ID: <060.18f012583ccaf7948c9c305ece6c1af5@haskell.org> #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------------------------------+------------------------- Reporter: jfeltz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Test Case: :set -XCPP followed by | Unknown :unset -XCPP | Blocked By: Blocking: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Is `:unset -XExt` the same as `:set -XNoExt`? Probably not for extensions that are on by default. This looks like a ticket suitable for new contributors to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 07:24:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 07:24:47 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.e018120d68eb78068efc4581624fd535@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by nomeata): (Even more crazy idea: One can even take this further. What about `case x of Right str -> Just str`. `Right` and `Just` can be used interchangeable at runtime (same constructor number, same number of arguments of the same shape). The compiler could create only one constructor for each such shape, and optimize the code above to `case x of Right _ -> x`. Furthermore we could have representational coercions between datatypes that are ?-equal... Although I doubt that the run-time benefit of that will be high, and we?d lose all hopes to implement something like `vacuum` or `ghc-vis`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 08:15:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 08:15:04 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.147408dfcce2a6d0b0e97d76cd55f348@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): I would be less interested in the cost of the operation as much as I would be interested in the possibility that the CSE could merge multiple branches, which means loops can be tighter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 08:36:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 08:36:04 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.ffaa5fea6b3cde15b05cf119402ee2e5@haskell.org> #8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 08:40:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 08:40:20 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.130fc22dd3c6b63cef9e4f1e16a3a6bf@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by jstolarek): * owner: simonpj => jstolarek Comment: Simon, I'm stealing this one from you :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 10:21:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 10:21:16 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.287c3be8aab05972d32dc1a7c7f2fcc6@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by nomeata): > I would be less interested in the cost of the operation as much as I would be interested in the possibility that the CSE could merge multiple branches, which means loops can be tighter. Your idea is absolutely glorious. If you worry about small resulting code, then doing the transformation in STG (which is untyped) might be feasible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 10:54:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 10:54:38 -0000 Subject: [GHC] #9295: Deadlock in forkProcess Message-ID: <044.090d8a79b478134070085ba877094a40@haskell.org> #9295: Deadlock in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- As part of `forkProcess` we discard all tasks except the one task that remains. As part of this we call `freeTask`, and `freeTask` in turn calls `closeCondition` and `closeMutex`, which are very thin wrappers around `pthread_cond_destroy` and `phread_mutex_destroy`. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently. For the global mutex we don't attempt to call `pthread_cond_destroy` or `pthread_mutex_destroy`, but instead re-initialize them. The patch https://phabricator.haskell.org/D59 does precisely that for the condition variables and mutexes associated with tasks. This is ''somewhat'' or a long way around, because we will then subsequently still call `pthread_..._destroy`, but it means that we don't have to mess with `freeTask`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 11:05:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 11:05:20 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess Message-ID: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- In `forkProcess` we acquire a bunch of mutexes so make sure that when we fork the child doesn't see an inconsistent state of any global data structures. However, we do not acquire the `all_tasks_mutex`, which means that the child might have an inconsistent view of the `all_tasks` list. https://phabricator.haskell.org/D60 Sadly, I do not have a test case illustrating that this is in fact a problem. Found this while working tracking down a deadlock in forkProcess (https://ghc.haskell.org/trac/ghc/ticket/9295). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 11:40:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 11:40:43 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.9785bc41b15a91e77017cf15d11f0872@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 11:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 11:41:38 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.6c1c24307cb70bf63f00234de9442355@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 11:52:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 11:52:40 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.9b766b30b04b465ccf6e6c47faad886a@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 11:53:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 11:53:30 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.44ae3110971858b06ea808aff01c1f58@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 12:10:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 12:10:31 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.730e7c83cf9b55a2f08d8014c8c7dc33@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Yeah, I thought about that too, but I couldn't see anything different in the file descriptors in deadlocking runs and non-deadlocking runs -- but that was purely based on the file descriptor _numbers_ (9, 4, 8), so you may of course still be right. I didn't manage to verify or refute this :/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 12:27:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 12:27:21 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.8a4fe01ce1d6c395fedecfdbebcc2fd4@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions --------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): As a brain-dump, here's the new representation I'm working on (which happens to make it trivial to provide a natural number type `Nat`): {{{#!hs type GmpLimb = Word -- actually, 'CULong' type GmpSize = Int -- actually, 'CLong' -- | Type representing /pure/ BigNats -- -- @ByteArray#@ is interpreted as an unboxed array of 'GmpLimb's -- -- Invariants: -- -- - ByteArray#'s size is the exact multiple of non-zero limbs (but never empty) -- - @0@ is represented as a 1-limb (available as 'bnZero') data BigNat = BN# ByteArray# -- | Invariant: 'NatJ#' is used iff value doesn't fit in 'NatS#' data Nat = NatS# {-# UNPACK #-} !GmpLimb | NatJ# {-# UNPACK #-} !BigNat -- | Invariant: 'Jn#'/'Jp#' are used iff value doesn't fit in 'S#' -- -- NB: less than 4 constructors allows pointer-tagging to work data Integer = S# {-# UNPACK #-} !Int | Jn# {-# UNPACK #-} !BigNat -- negative | Jp# {-# UNPACK #-} !BigNat -- positive }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 14:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 14:04:28 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.b119d4129c46b1fd9d40c9b5f5c6fb61@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by rwbarton): Replying to [comment:8 schyler]: > @rwbarton, does that still make it simple for the CSE to eliminate extra branches? Good question. I don't think it would get CSEd at the Core level, but hopefully it would in a later pass (STG or Cmm). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 15:33:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 15:33:26 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.d899b8a85963bcc8a1527a76574e09a1@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by RyanGlScott): I can confirm that this bug still exists on GHC 7.8.3 on Windows x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 16:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 16:56:15 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime Message-ID: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime ----------------------------------+--------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I am using GHC 7.8.3 on Windows 7, x86_64. When GHC loads certain packages at runtime, it gives some interesting warnings: {{{ > ghci -package haskeline GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package Win32-2.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package haskeline-0.7.1.2 ... linking ... ghc.exe: warning: SetConsoleCursorPosition from kernel32 is linked instead of __imp_SetConsoleCursorPosition ghc.exe: warning: FillConsoleOutputCharacterA from kernel32 is linked instead of __imp_FillConsoleOutputCharacterA ghc.exe: warning: FillConsoleOutputAttribute from kernel32 is linked instead of __imp_FillConsoleOutputAttribute done. Prelude> }}} Besides {{{haskeline}}}, other packages with similar problems include {{{unix-compat}}}, {{{network}}}, and {{{regex-posix}}}. To see them all at once, you can run the [{{{hermit-web}}} https://github.com/ku-fpg /hermit-web] executable: {{{ > hermit-web Last.hs [starting HERMIT-Web v0.1.0.0 on Last.hs] [starting HERMIT v0.5.0.0 on Last.hs] % ghc Last.hs -fforce-recomp -O2 -dcore-lint -fsimple-list-literals -fexpose-all-unfoldings -fplugin=HERMIT.Web -fplugin-opt=HERMIT.Web:*: [1 of 1] Compiling Main ( Last.hs, Last.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package Win32-2.3.0.2 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.1.3 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.1 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.8.3 ... linking ... done. Loading package haskeline-0.7.1.2 ... linking ... ghc: warning: SetConsoleCursorPosition from kernel32 is linked instead of __imp_SetConsoleCursorPosition ghc: warning: FillConsoleOutputCharacterA from kernel32 is linked instead of __imp_FillConsoleOutputCharacterA ghc: warning: FillConsoleOutputAttribute from kernel32 is linked instead of __imp_FillConsoleOutputAttribute done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.2.0 ... linking ... done. Loading package scientific-0.3.2.2 ... linking ... done. Loading package attoparsec-0.12.1.0 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package syb-0.4.2 ... linking ... done. Loading package unordered-containers-0.2.5.0 ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package aeson-0.7.0.6 ... linking ... done. Loading package blaze-builder-0.3.3.2 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package ansi-terminal-0.6.1.1 ... linking ... done. Loading package kure-2.16.2 ... linking ... done. Loading package marked-pretty-0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package operational-0.2.3.2 ... linking ... done. Loading package stm-2.4.3 ... linking ... done. Loading package exceptions-0.6.1 ... linking ... done. Loading package temporary-1.2.0.3 ... linking ... done. Loading package hermit-0.5.0.0 ... linking ... done. Loading package case-insensitive-1.2.0.0 ... linking ... done. Loading package http-types-0.8.5 ... linking ... done. Loading package transformers-base-0.4.2 ... linking ... done. Loading package monad-control-0.3.3.0 ... linking ... done. Loading package lifted-base-0.2.3.0 ... linking ... done. Loading package mmorph-1.0.3 ... linking ... done. Loading package resourcet-1.1.2.2 ... linking ... done. Loading package nats-0.2 ... linking ... done. Loading package semigroups-0.15.1 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package conduit-1.1.6 ... linking ... done. Loading package regex-base-0.93.2 ... linking ... done. Loading package regex-posix-0.95.2 ... linking ... ghc: warning: isupper from msvcrt is linked instead of __imp_isupper ghc: warning: toupper from msvcrt is linked instead of __imp_toupper ghc: warning: tolower from msvcrt is linked instead of __imp_tolower ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha ghc: warning: iscntrl from msvcrt is linked instead of __imp_iscntrl ghc: warning: isupper from msvcrt is linked instead of __imp_isupper ghc: warning: isgraph from msvcrt is linked instead of __imp_isgraph ghc: warning: isprint from msvcrt is linked instead of __imp_isprint ghc: warning: ispunct from msvcrt is linked instead of __imp_ispunct ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum done. Loading package regex-compat-0.95.1 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package network-2.5.0.0 ... linking ... ghc: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc: warning: accept from ws2_32 is linked instead of __imp_accept ghc: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo done. Loading package vault-0.3.0.3 ... linking ... done. Loading package wai-3.0.0.2 ... linking ... done. Loading package base64-bytestring-1.0.0.1 ... linking ... done. Loading package fast-logger-2.1.5 ... linking ... done. Loading package zlib-0.5.4.1 ... linking ... done. Loading package streaming-commons-0.1.3.1 ... linking ... done. Loading package stringsearch-0.3.6.5 ... linking ... done. Loading package byteorder-1.0.4 ... linking ... done. Loading package wai-logger-2.1.1 ... linking ... done. Loading package word8-0.0.4 ... linking ... done. Loading package wai-extra-3.0.1 ... linking ... done. Loading package conduit-extra-1.1.1 ... linking ... done. Loading package simple-sendfile-0.2.15 ... linking ... done. Loading package unix-compat-0.4.1.3 ... linking ... ghc: warning: GetVersionExA from kernel32 is linked instead of __imp_GetVersionExA ghc: warning: GetModuleHandleA from kernel32 is linked instead of __imp_GetModuleHandleA ghc: warning: GetProcAddress from kernel32 is linked instead of __imp_GetProcAddress ghc: warning: _snprintf from msvcrt is linked instead of __imp__snprintf ghc: warning: GetSystemInfo from kernel32 is linked instead of __imp_GetSystemInfo ghc: warning: GetSystemMetrics from user32 is linked instead of __imp_GetSystemMetrics ghc: warning: GetVersionExA from kernel32 is linked instead of __imp_GetVersionExA ghc: warning: _snprintf from msvcrt is linked instead of __imp__snprintf ghc: warning: GetSystemInfo from kernel32 is linked instead of __imp_GetSystemInfo ghc: warning: GetComputerNameA from kernel32 is linked instead of __imp_GetComputerNameA ghc: warning: CryptAcquireContextA from advapi32 is linked instead of __imp_CryptAcquireContextA ghc: warning: CryptGenRandom from advapi32 is linked instead of __imp_CryptGenRandom ghc: warning: _stat64 from msvcrt is linked instead of __imp__stat64 ghc: warning: _open from msvcrt is linked instead of __imp__open ghc: warning: _stat64 from msvcrt is linked instead of __imp__stat64 done. Loading package warp-3.0.0.4 ... linking ... done. Loading package scotty-0.8.1 ... linking ... done. Loading package hermit-web-0.1.0.0 ... linking ... done. Setting phasers to stun... (port 3000) (ctrl-c to quit) }}} These warnings seem to be related to Windows-specific {{{.dll}}} files, including {{{kernel32.dll}}}, {{{user32.dll}}}, {{{msvcrt.dll}}}, {{{advapi32.dll}}}, and {{{ws2_32.dll}}}. As far as I can tell, there are no problems other than the warnings themselves, but I can't be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 17:11:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 17:11:19 -0000 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@haskell.org> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@haskell.org> Message-ID: <059.b79d063734e2192321a343e8c85d9b6a@haskell.org> #2356: GHC accepts multiple instances for the same type in different modules -------------------------------------+------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5316 -------------------------------------+------------------------------------ Comment (by rwbarton): You can get this kind of instance incoherence without orphan instances or any extensions beyond `FlexibleInstances`. See https://gist.github.com/rwbarton/dd8e51dce2a262d17a80. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 20:53:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 20:53:00 -0000 Subject: [GHC] #9298: ghc.exe: internal error: evacuate: strange closure type 365488164 Message-ID: <049.d765684266b06afdaa0f98beceafc02b@haskell.org> #9298: ghc.exe: internal error: evacuate: strange closure type 365488164 ------------------------------+--------------------------------------- Reporter: Tominator2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: idris | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------------- after saying "cabal install idris" the machine churned for a while, spitting out messages, then said: src\Idris\AbsSyntax.hs:1569:10: Warning: `EitherErr' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. ghc.exe: internal error: evacuate: strange closure type 365488164 (GHC version 7.8.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Failed to install idris-0.9.13.1 cabal.exe: Error: some packages failed to install: idris-0.9.13.1 failed during the building phase. The exception was: ExitFailure 3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 11 22:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jul 2014 22:04:51 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.164d761c815c6a7657981dd309567e85@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts ---------------------------------------+---------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by rwbarton): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 03:25:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 03:25:56 -0000 Subject: [GHC] #9299: GHCi type inference error Message-ID: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> #9299: GHCi type inference error ------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This code (required conduit-1.1.6): {{{ {- Bolled down from https://github.com/snoyberg/conduit/blob/process/conduit- extra/Data/Conduit/Process.hs -} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE RankNTypes #-} import System.Process import Control.Monad.IO.Class (MonadIO, liftIO) import System.IO (Handle, hClose) import Data.Conduit import Data.ByteString (ByteString) import Data.Maybe (fromMaybe) import Control.Applicative ((<$>), (<*>)) data UseProvidedHandle = UseProvidedHandle data Inherited = Inherited data ClosedStream = ClosedStream class InputSource a where isStdStream :: (Maybe Handle -> IO a, Maybe StdStream) instance InputSource Handle where isStdStream = (\(Just h) -> return h, Just CreatePipe) instance InputSource ClosedStream where isStdStream = (\(Just h) -> hClose h >> return ClosedStream, Just CreatePipe) instance (r ~ (), MonadIO m, i ~ ByteString) => InputSource (ConduitM i o m r) where isStdStream = (\(Just h) -> return $ sinkHandle h, Just CreatePipe) instance (r ~ (), r' ~ (), MonadIO m, MonadIO n, i ~ ByteString) => InputSource (ConduitM i o m r, n r') where isStdStream = (\(Just h) -> return (sinkHandle h, liftIO $ hClose h), Just CreatePipe) instance InputSource Inherited where isStdStream = (\Nothing -> return Inherited, Just Inherit) instance InputSource UseProvidedHandle where isStdStream = (\Nothing -> return UseProvidedHandle, Nothing) sinkHandle :: MonadIO m => Handle -> Consumer ByteString m () sinkHandle = error "sinkHandle" conduitProcess :: (MonadIO m, InputSource stdin) => CreateProcess -> m (stdin, ProcessHandle) conduitProcess cp = liftIO $ do let (getStdin, stdinStream) = isStdStream (stdinH, _, _, ph) <- createProcess cp { std_in = fromMaybe (std_in cp) stdinStream } (,) <$> getStdin stdinH <*> return ph main :: IO () main = putStrLn "Hello" }}} Compiles fine with ghc, and runs correctly with `runghc`, but fails to load into ghci with the following error: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:45:9: No instance for (InputSource a0) arising from the ambiguity check for ?stdinStream? The type variable ?a0? is ambiguous When checking that ?stdinStream? has the inferred type ?Maybe StdStream? Probable cause: the inferred type is ambiguous In the second argument of ?($)?, namely ?do { let (getStdin, stdinStream) = isStdStream; (stdinH, _, _, ph) <- createProcess (cp {std_in = fromMaybe (std_in cp) stdinStream}); (,) <$> getStdin stdinH <*> return ph }? In the expression: liftIO $ do { let (getStdin, stdinStream) = isStdStream; (stdinH, _, _, ph) <- createProcess (cp {std_in = fromMaybe (std_in cp) stdinStream}); (,) <$> getStdin stdinH <*> return ph } Failed, modules loaded: none. }}} Same problem in 7.6.3, 7.8.2 and 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 04:09:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 04:09:56 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.753aba80c942df6b6f3808a006a11faa@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by erikd): From #ghc on Freenode: {{{ Here's my theory. The difference between GHC and GHCi is extended defaulting. InputSource is only eligible for extended defaulting, not regular defaulting. So, when loaded in ghci, it's getting defaulted, which is ambiguous. Whereas in ghc, it doesn't get defaulted, and correctly gets tied to the stdin variable in the signature of conduitProcess. None of the instances for InputSource are on the defaulting list, which is why it's ambiguous. I don't understand why defaulting would kick in, though. It's like it's overly aggressive. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 04:11:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 04:11:51 -0000 Subject: [GHC] #9300: Enhancing your stamina and makes you strong and healthy Message-ID: <051.b68ca0034011ab5bb669b44663416c21@haskell.org> #9300: Enhancing your stamina and makes you strong and healthy -----------------------------------------+--------------------------------- Reporter: lawooryajeek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Jacked Muscle Extreme | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- The tax themselves to properly develop the chest the shortest forward from a backward track position tour that help spur squeeze to the point for contractions shoulder style forward and excellent work directly well the flat barbell bench press has always been one of the most popular upper body exercises because it not only develop the pectoral muscles put the triceps and the front deltoids as well however because so many different muscles are involved when you do bench presses be sure to use wide enough grip to bring the pack forcefully into play narrow grip forces the triceps to do disproportionate amount of [http://jackedmuscleextremefacts.com/ Jacked Muscle Extreme] work as we'll see later bring the bar down deliberately and under full control the negative or eccentric part of the breath is as important as the concentrate or positive lifting partisan movement over the bar to the middle of the chestnut too far up toward the neck stop then press it back up to full lockout position feeling the shoulders pressing forward and the chest muscles contracting if you live just with your arms with this exercise you'll never get the kind of chest development you're looking for bringing the bar to a full stop at the bottom is important when you balance the weight off your chest you risk injury and take away from the difficulty of the exercise so if you want full intensity from the bench press lower the bar to the chest and come to a full stop before pressing up against when you doing the bench press be sure to control the bar the speed at which it comes up and down and how far down you're going you don't want to forgive push your body back which were your chest is being over expanded and your arms a big push to the sides you feeling this caring sensation in the PEC Dec area issue guys. http://jackedmuscleextremefacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 04:54:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 04:54:24 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * Message-ID: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> #9301: Rank-2 constraints are assigned kind * ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Compile this program with GHC-HEAD (I have 7.9.20140605, but I guess 7.8.3 will also do): {{{ {-# LANGUAGE RankNTypes #-} strangelet :: (forall t . Num t) => () strangelet = \_ -> () }}} Very strangely it gets accepted! {{{ *Main> :t strangelet strangelet :: (forall t. Num t) -> () }}} I suspect that the type checker assigns kind `*` to rank-2 constraints. Of course it should assign a `Constraint` kind. What I ultimately want is to declare: {{{ foo :: (Monad m, forall n . Num (m n)) => m n foo = ... }}} ..or such. Would that be unreasonable? NB: 7.4.2 rejects it (even with `-XConstraintKinds`). I did not try 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 05:00:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 05:00:01 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * In-Reply-To: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> References: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> Message-ID: <063.b6e04ccd56b8069785c41eece67eaa1f@haskell.org> #9301: Rank-2 constraints are assigned kind * -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by heisenbug: Old description: > Compile this program with GHC-HEAD (I have 7.9.20140605, but I guess > 7.8.3 will also do): > {{{ > {-# LANGUAGE RankNTypes #-} > > strangelet :: (forall t . Num t) => () > strangelet = \_ -> () > }}} > > Very strangely it gets accepted! > {{{ > *Main> :t strangelet > strangelet :: (forall t. Num t) -> () > }}} > I suspect that the type checker assigns kind `*` to rank-2 constraints. > Of course it should assign a `Constraint` kind. > > What I ultimately want is to declare: > {{{ > foo :: (Monad m, forall n . Num (m n)) => m n > foo = ... > }}} > ..or such. Would that be unreasonable? > > NB: 7.4.2 rejects it (even with `-XConstraintKinds`). I did not try > 7.6.3. New description: Compile this program with GHC-HEAD (I have 7.9.20140605, but I guess 7.8.3 will also do): {{{ {-# LANGUAGE RankNTypes #-} strangelet :: (forall t . Num t) => () strangelet = \_ -> () }}} Very strangely it gets accepted! {{{ *Main> :t strangelet strangelet :: (forall t. Num t) -> () }}} I suspect that the type checker assigns kind `*` to rank-2 constraints. Of course it should assign a `Constraint` kind. What I ultimately want is to declare: {{{ foo :: (Monad m, forall n . Num (m n)) => m n foo = ... }}} ...or such. Would that be unreasonable? NB: 7.4.2 rejects it (even with `-XConstraintKinds`). I did not try 7.6.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 05:29:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 05:29:19 -0000 Subject: [GHC] #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) In-Reply-To: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> References: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> Message-ID: <060.c66c5cb26a723be05095a2f854d1d6a4@haskell.org> #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): A more appropriate name addrOf# maybe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 05:38:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 05:38:09 -0000 Subject: [GHC] #9302: Ingredients are safe free herbal natural Message-ID: <051.4764566263ecdb5aaed4123ee3f96d16@haskell.org> #9302: Ingredients are safe free herbal natural -----------------------------------------+--------------------------------- Reporter: lawooryajeek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Jacked Muscle Extreme | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- The farmer the close grip on the other hand forces the arms to work through a much longer range of motion while the link above the chest contractions short this turns the press into a triceps rather than a pectoral exercised along with tips done with the body in an upright positions close grip barbell press is our primary masses great building exercised for developing the triceps using a smith machine has many of the advantages of training with the barbell without some other disadvantages which makes close grip presses on the smith machine an attractive alternative for close grip barbell precedence for example the fact that you don't have to balance and control the bar to the same degree allows you to keep your hands even closer together than when doing the exercise with the freeway but you're still lifting against the force of gravity which gives you like three just response an adaptation from the muscles so the result is the ability to achieve them maximum amount of isolation in your triceps training along with the strongest contraction of the muscles and these two elements as up to the utmost the intensity in your triceps [http://jackedmuscleextremefacts.com/ Jacked Muscle Extreme] training bench dips are a kind of a paradox oppressing movement done with the isolation and strictness 7 extension exercise as with parallel bar dips below are you going this movement the more intensity you generate as a matter a fact bench dips tend to beery popular with women many of whom like the upper body strength to do parallel bar dips when they first start raining but you donned to exercise proper care with this movement never drop down so far that your risk over stretching the muscles tendons and ligaments and incurring an injury keep the movement?s moved steady and under full control at all times for maximum development at the triceps try alternating bench depth with upright parallel park just in. http://jackedmuscleextremefacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 06:14:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 06:14:08 -0000 Subject: [GHC] #9303: This product provides visible benefits to all men without any age discrimination Message-ID: <051.66bdbada0b041ea382bbf098bd5ea366@haskell.org> #9303: This product provides visible benefits to all men without any age discrimination ------------------------------------------+-------------------------------- Reporter: lawooryajeek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Jacked Muscle Extremec | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ------------------------------------------+-------------------------------- Who actually the upper chest this has to give such a faggot ill that hits the lower chest this bench doesn't allow that enables therefore improvise what I have right here and the chance you guys might have an account you might have a pension actually just I don?t for the goal here to keep this angle here so are we activate the lower portion over chest fear that's why I have here it was as hit man a slut load is getting too coming up guys thanks for the help to come that way for the fall it other tests like you basically pushing the 40 parallel well for your body so that the class you legal at or below for the chess you go closer he is organized for the borough more inside the chest working as you bring his hands out further looking more the mass building on the out a four-ship says yes it does 360 this change up your replacement always kunai replace comments I walk outside one cool really what for what to change up keep the muscle confusion practiced said event all that we saw still fire place to live your keyboard him that we're not meant for football fire this me she lucky then well there is a [http://jackedmuscleextremefacts.com/ Jacked Muscle Extreme] waffle behind Smith couple over here is fashioned here for me. of course we'll ask her to glow a shorter with coming down to see portion guys at on the decline for 25 the chest with your for scripts FRL party what's this workout business to plan attacks to ensure use of yourself reached massive potential a few capabilities guys polished platinum 28 I guarantee success guys just looking like you must have a plan of action for your life if you don't guarantee you become the plant someone else's life this right guys the final exercise numbers even lucky 7 man as you can tell my aunt low below as with text on it the whole time you guys is that your balls to the wall still mad again what have you been doing up to this point were even here. http://jackedmuscleextremefacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 08:13:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 08:13:23 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.1a9a973cf14d628b34e6e6698e045dcb@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions --------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by ekmett): Eliminating the need for the GMP custom allocator would be a _huge_ win for interoperability, and would obviate the need for code I've spent months writing. If you need anything from me just ask. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 09:14:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 09:14:57 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC Message-ID: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------+---------------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 09:17:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 09:17:42 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.8a4959c1018a1779a74b27e886e2c0b2@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------------+---------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by ulysses4ever): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 09:28:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 09:28:55 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.0d21566981c8aa80f38aeb1a210173db@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by erikd): * version: 7.8.2 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 09:44:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 09:44:59 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.a32ff7b1ab4dbe9e407cef0e5379bb64@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------------+---------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Description changed by ulysses4ever: Old description: > I followed ?First steps? section in > [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to > build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). > During the last step (make) it comes to the error: > > {{{ > /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- > install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation > R_X86_64_PC32 against undefined symbol > `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > }}} New description: I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The only substantial change I did to the manual is setting BuildFlavour = quickest instead of BuildFlavour = quick. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 10:32:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 10:32:13 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp Message-ID: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp ----------------------------------+--------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- {{{ ghc --make -O2 M.hs [1 of 1] Compiling M ( M.hs, M.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As in #9155 bug was caught on '''wx''' package in the same module. I didn't try to trim it down to minimal sample. No external modules required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 10:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 10:56:54 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.83a6f53ffa67418e4535d7dadd49c14d@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by slyfox): The same for -HEAD: {{{ (GHC version 7.9.20140710 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s12v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 11:08:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 11:08:24 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.5dbd927ec5028079350e34b79b075d1d@haskell.org> #8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Comment (by George): Is this true for both the new code generator and llvm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 11:09:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 11:09:30 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.7d2bb71fce40fa21f669aeb7eda7367e@haskell.org> #8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 11:36:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 11:36:49 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.3829ad563b48ec2e43d7549e726f9ae5@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by erikd): * version: 7.8.3 => 7.6.3 Comment: Setting version to earliest version I've tested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 14:11:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 14:11:22 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * In-Reply-To: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> References: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> Message-ID: <063.aa3d0b6daa30a4e1f4c0b931570480e7@haskell.org> #9301: Rank-2 constraints are assigned kind * -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Running GHC with debug options `ghci -XRankNTypes -XConstraintKinds -ddump-parsed -ddump-rn -ddump-types -ddump-tcstrangelet.hs` I get: {{{ ==================== Parser ==================== strangelet :: forall t. Num t => () strangelet = \ _ -> () ==================== Renamer ==================== Main.strangelet :: forall t. Num t => () Main.strangelet = \ _ -> () TYPE SIGNATURES strangelet :: (forall t. Num t) -> () TYPE CONSTRUCTORS COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] ==================== Typechecker ==================== AbsBinds [] [] {Exports: [strangelet <= strangelet <>] Exported types: strangelet :: (forall t. Num t) -> () [LclId, Str=DmdType] Binds: strangelet = \ _ -> GHC.Tuple.()} Ok, modules loaded: Main. }}} The renamer still has it right, while both `-ddump-types -ddump-tc` already show the wrong signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 14:41:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 14:41:27 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.7b17e72211b9b0c42c1613c8cb265db9@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------------+---------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by ulysses4ever): * version: 7.8.2 => * architecture: x86_64 (amd64) => Unknown/Multiple Old description: > I followed ?First steps? section in > [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to > build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). > During the last step (make) it comes to the error: > > {{{ > /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- > install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation > R_X86_64_PC32 against undefined symbol > `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > }}} > > The only substantial change I did to the manual is setting BuildFlavour = > quickest instead of BuildFlavour = quick. New description: I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The only substantial change I did to the manual is setting BuildFlavour = quickest instead of BuildFlavour = quick. I tried to just the same under Lubuntu 13.04 (i386) and got just the same type of error on relocation (now for R_386_GOTOFF symbol) in the same module (Data.Array.Parallel). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 15:10:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 15:10:39 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.ab3a42a1d61680d6cef56e2d398714d3@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------------+---------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Description changed by ulysses4ever: Old description: > I followed ?First steps? section in > [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to > build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). > During the last step (make) it comes to the error: > > {{{ > /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- > install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation > R_X86_64_PC32 against undefined symbol > `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > }}} > > The only substantial change I did to the manual is setting BuildFlavour = > quickest instead of BuildFlavour = quick. > > I tried to just the same under Lubuntu 13.04 (i386) and got just the same > type of error on relocation (now for R_386_GOTOFF symbol) in the same > module (Data.Array.Parallel). New description: I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The only substantial change I did to the manual is setting BuildFlavour = quickest instead of BuildFlavour = quick. I tried to just the same under Lubuntu 13.04 (i386) and got just the same type of error on relocation (now for R_386_GOTOFF symbol) in the same module (Data.Array.Parallel). Other related bug might be #9007. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 15:57:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 15:57:52 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.37bd7c08462ddb1f7205fdf0275e36dc@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by ulysses4ever): Are there any straightforward workarounds for this problem? I have similar issue while building GHC from sources (reported in #9302) when processing Data.Array.Parallel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 16:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 16:02:34 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour (was: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC) In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.0297db3d1eec46aef443050b57eb6a46@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour ----------------------------------------+---------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Description changed by ulysses4ever: Old description: > I followed ?First steps? section in > [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to > build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). > During the last step (make) it comes to the error: > > {{{ > /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- > install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation > R_X86_64_PC32 against undefined symbol > `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > }}} > > The only substantial change I did to the manual is setting BuildFlavour = > quickest instead of BuildFlavour = quick. > > I tried to just the same under Lubuntu 13.04 (i386) and got just the same > type of error on relocation (now for R_386_GOTOFF symbol) in the same > module (Data.Array.Parallel). > > Other related bug might be #9007. New description: I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} I tried to just the same under Lubuntu 13.04 (i386) and got just the same type of error on relocation (now for R_386_GOTOFF symbol) in the same module (Data.Array.Parallel). The only substantial change I did to the manual is setting BuildFlavour = quickest instead of BuildFlavour = quick. And it seems '''to be the cause'''. The error disappears when switch to quick flavour. Other related bug might be #9007. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 16:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 16:14:06 -0000 Subject: [GHC] #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) In-Reply-To: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> References: <045.46a839bae0d8b2b678bff8a2ecd917e7@haskell.org> Message-ID: <060.974d5955a12d1759f919869ff0fe2b44@haskell.org> #9289: add anyToAddr# :: (#a#)-> Addr# primop (inverse of addrToAny#) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): It won't be an address. In general, it could also be an Int# or Word# casted to an Addr# :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 19:26:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 19:26:59 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux Message-ID: <045.d05a83ce5d196096a6368324dde68686@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 20:38:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 20:38:29 -0000 Subject: [GHC] #9305: GHC panic when deriving Functor on a Fixed type Message-ID: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> #9305: GHC panic when deriving Functor on a Fixed type -----------------------------------+--------------------------------------- Reporter: andreyLevushkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------------- Building the following {{{ #!haskell {-# LANGUAGE DeriveFunctor#-} module Main where data Event a b = Event a deriving (Functor) newtype F f = F (f (F f)) data EventF a = EventF (F (Event a)) deriving (Functor) }}} results in {{{ Main.hs:7:48:ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Prelude.(!!): index too large }}} I am not sure if the above code should actually compile but it probably shouldn't panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 21:42:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 21:42:43 -0000 Subject: [GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite (was: ghc-7.9.20140707 fails testsuite on OS X () In-Reply-To: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> References: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> Message-ID: <057.38a096bc9d27237aea8d51fbfb65bad1@haskell.org> #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite ----------------------------------------------+---------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | testsuite Type of failure: Building GHC failed | Architecture: x86_64 Test Case: T5435_dyn_asm T4801 T6048 | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 22:18:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 22:18:40 -0000 Subject: [GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite In-Reply-To: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> References: <042.e5f3288a9db022942dd41ba3f45a10c9@haskell.org> Message-ID: <057.a3342c56aab859e308fff2b1c95bf7c3@haskell.org> #9286: ghc-7.9.20140707 fails testsuite on OS X (10.10) Yosemite ----------------------------------------------+---------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | testsuite Type of failure: Building GHC failed | Architecture: x86_64 Test Case: T5435_dyn_asm T4801 T6048 | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jrp): ... and with today's HEAD, running fulltest, with ghc built with BuildFlavour = perf-llvm (3.4.2) {{{ Unexpected results from: TEST="T367_letnoescape AtomicPrimops T367 conc012 callstack001 enum01 topHandler03 enum03 enum02 T5550 T7702 qq008 haddock.Cabal objc-hi objcpp- hi T7837 T4801 T6048 T9078 divbyzero overflow3 overflow2 overflow1 derefnull T5435_dyn_asm T7919 qq007 T9203 signals004" OVERALL SUMMARY for test run started at Sat Jul 12 18:24:35 2014 BST 4:27:38 spent to go through 4039 total tests, which gave rise to 19421 test cases, of which 4248 were skipped 165 had missing libraries 14800 expected passes 135 expected failures 0 caused framework failures 0 unexpected passes 73 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) ../../libraries/unix/tests signals004 [bad exit code] (threaded2) concurrent/should_run AtomicPrimops [bad exit code] (profasm,profthreaded) concurrent/should_run T367 [bad exit code] (profasm,profthreaded) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) indexed-types/should_compile T7837 [stderr mismatch] (profasm) perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) profiling/should_run callstack001 [bad stdout] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts T5435_dyn_asm [bad stdout] (normal) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts overflow1 [bad exit code] (hpc,optasm,profasm,threaded2,dyn,profthreaded,optllvm) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) simplCore/should_compile T7702 [stat not good enough] (hpc,optllvm) simplCore/should_compile T7702 [exit code non-0] (profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 22:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 22:27:59 -0000 Subject: [GHC] #9305: GHC panic when deriving Functor on a Fixed type In-Reply-To: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> References: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> Message-ID: <069.05cf61988fc3319c0e4c41ebdc28a75b@haskell.org> #9305: GHC panic when deriving Functor on a Fixed type ---------------------------------------+---------------------------------- Reporter: andreyLevushkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Joachim Breitner ): In [changeset:"47640ca4e5cdb2882f0b30dec7b34f8c5c734171/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47640ca4e5cdb2882f0b30dec7b34f8c5c734171" Test case for #9305 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 22:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 22:29:24 -0000 Subject: [GHC] #9305: GHC panic when deriving Functor on a Fixed type In-Reply-To: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> References: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> Message-ID: <069.91543094418f68885c0025921efcdb37@haskell.org> #9305: GHC panic when deriving Functor on a Fixed type ---------------------------------------+---------------------------------- Reporter: andreyLevushkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: T9305 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by nomeata): * testcase: => T9305 Comment: I get {{{ T9305.hs:8:48: No instance for (Functor Event) arising from the first field of ?EventF? (type ?F (Event a)?) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Functor EventF) }}} when trying with GHC head. I?m not quite sure if its the best error message, but it looks better than what you report, hence adding it as a (non-broken) test case. If convenient, can you check if it still happens with 7.8.3? Might be an already fixed and merged bug. Otherwise we should identify the fix and merge it for 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 22:37:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 22:37:04 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.77f14a644ca1b489d6e80124b8781e18@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by schyler): * blockedby: => 9276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 12 22:38:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jul 2014 22:38:18 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.ad743c787c796b1e1baed0bfedcaddd6@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9304 | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Ideally, adapters should be used to emulate floating point behaviour. I'm not sure how complex it is, but you shouldn't lose any optimisations in cross compiling -- what if cross compiling is normal, i.e. embedded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 00:43:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 00:43:13 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.a26b65102c9bafd03e154f2428dc81d7@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): could you try building the 32bit linux code with -sse2? otherwise on 32bit system I BELIEVE the x87 (80bit) floats will be used. It could be simply that you're using the 80bit floats! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 00:45:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 00:45:31 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.c86a950ebc00a403ca8b28beedf89f18@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9304 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Yeah, improving optimization requires a pretty precise soft float model of the target hardware's floating point semantics, with roughly three modes 1. IEEE / machine model -- same result as if run as a normal program 2. fast math model -- assume associativity, assume NaNs never happen 3. excess precision -- use extra precision in the intermediate computation to provide as many bits of precision as possible adding that sort of machinery to ghc is a bit out of scope for just an audit (and any induced patched to provide added missing operations), but becomes possible once such an audit is done. (Also a LOT of work) I want to get this done for 7.10, adding optimization on top can be on the table later though! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 00:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 00:49:33 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.dd771e9ce7787bf215b7f00a58db1b07@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9304 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): though if someone writes that soft model tooling for at least case (1), maybe it could happen faster! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 01:52:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 01:52:23 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.b9043a74650521ec460b0b2c8d34dea4@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): Carter: I compiled with the "-msse2" flag; and I still see the same response on linux; it still differs from the one I see on the Mac. If someone can try on a true 64-bit linux machine, that'd be really good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 03:03:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 03:03:29 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.771882ba3533f278283f5b4b5be80495@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I ran it on a 64 bit linux server i have using ghci {{{ Prelude> :set -XScopedTypeVariables Prelude> let x :: Double = -4.4 Prelude> let y :: Double = 2.4999999999999956 Prelude> decodeFloat (x*y) (-6192449487634421,-49) }}} so if anything, it looks like its 32bit vs 64bit could you try running the above snippet in GHCi on your 32bit machine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 04:11:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 04:11:23 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.9cf5e80f1449a4f3f662120e832b5c33@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): So, it appears that the one ending with 21 is the likely correct result; as opposed to 22. Is this an issue with some underlying library (glibc etc.); or an issue with GHC itself? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 04:38:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 04:38:28 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.59692b174f22e1520f93a3d4338838cc@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): its the last bit, it could just be different rounding! lets not assume anything is wrong, it could be both are compliant what is your linux distro and hardware and cpu? could you give me more information? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 07:45:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 07:45:42 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.3472b360472e458af636db62b65b4512@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Fyi, `decodeFloat` is based on somewhat hacky C implementation inside `integer-gmp`: source:ghc/libraries/integer-gmp/cbits/float.c#L191 I wouldn't be surprised if the C implementation was slightly unsound... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 08:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 08:07:18 -0000 Subject: [GHC] #9306: Crash when shifting Integers too much Message-ID: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> #9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer at lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 08:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 08:15:07 -0000 Subject: [GHC] #9306: Crash when shifting Integers too much In-Reply-To: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> References: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> Message-ID: <060.0443221668ef6fb1cba897b348a1380f@haskell.org> #9306: Crash when shifting Integers too much -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): The problem here is that the shift amount is of type `Int`, so `fromIntegral (maxBound::Int) + 1` is actually `minBound`, so the code {{{#!hs okay = 1000 `shiftR` (fromIntegral (maxBound::Int) + 1) :: Integer tooFar = 1 `shiftR` (fromIntegral (maxBound::Int) + 2) :: Integer }}} is the same as {{{#!hs okay = 1000 `shiftR` minBound :: Integer tooFar = 1 `shiftR` (minBound + 1) :: Integer }}} And both should have overflowed, as you are effectively requesting a left- shift by a *huge* amount -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 08:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 08:22:09 -0000 Subject: [GHC] #9306: Crash when shifting Integers too far left (was: Crash when shifting Integers too much) In-Reply-To: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> References: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> Message-ID: <060.ab390059aa2a7722ded7ac4b98bfe7cc@haskell.org> #9306: Crash when shifting Integers too far left -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by dfeuer: Old description: > When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, > the RTS crashes. The attached program gives the following output (on > x86_64, at least): > > [dfeuer at lemur src]$ ./shiftcrash > Okay 0 > gmp: overflow in mpz type > Aborted > > I found the bug in 7.6.3, but it's been verified to be present also in > 7.8.3. The crash also occurs when running similar code in GHCi. New description: When shifting an Integer very far left, the RTS crashes. On x86_64: Prelude Data.Bits> 1 `shiftL` 100000000000000000000000 == 1 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code compiled by ghc. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 08:26:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 08:26:10 -0000 Subject: [GHC] #9305: GHC panic when deriving Functor on a Fixed type In-Reply-To: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> References: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> Message-ID: <069.ddc18a793ad23c63e16a2dd3860d77b8@haskell.org> #9305: GHC panic when deriving Functor on a Fixed type ---------------------------------------+---------------------------------- Reporter: andreyLevushkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: T9305 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: This is already fixed in 7.8.3 (#9071, #9255) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 08:34:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 08:34:19 -0000 Subject: [GHC] #4102: Bit manipulation built-ins In-Reply-To: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> References: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> Message-ID: <064.11d213762d415515715ac14f7756b551@haskell.org> #4102: Bit manipulation built-ins -------------------------------------+------------------------------------ Reporter: uzytkownik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by dfeuer): * cc: dfeuer, hvr, ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 09:29:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 09:29:44 -0000 Subject: [GHC] #5014: canonicalizePath throws exception on paths that do not exist In-Reply-To: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> References: <048.38fed68301267b4479d1736f2f71b59d@haskell.org> Message-ID: <063.9d672609a6458bffda08966ffb429659@haskell.org> #5014: canonicalizePath throws exception on paths that do not exist ----------------------------------------+---------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/directory | Version: 7.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Blaisorblade): Documenting the current behavior is better than nothing, but settling on that seems a regression from portable languages to C. I want to argue that settling on platform-dependent behavior is a worse idea than figuring out a sensible platform-independent behavior, possibly by surveying other languages (Python as proposed above, or maybe Java). Additional system-specific APIs are probably fine for lower-level development, but they seem lower-priority to me. This bug keeps causing portability problems for Haskell applications. I remember cabal needed fixing for this; right now I ran into this for hp2any-graph, which tries to canonicalize a filename that is going to appear. Therefore, quite a few programs that use canonicalizePath and were developed on Linux only break on other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 09:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 09:45:33 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.34c8fa8e13698edf0202849a4ff6814d@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): > I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. I personally wouldn't expect that at all. I'd expect it all comes down to whether the optimizer decided to keep the intermediate result in a larger temporary because it ran it through the old x87 hardware or if it decided to go through SSE, etc. This will happen. It will give different answers, even on the same machine and OS at different call sites, when the optimizer spits out different code for different inlinings, etc. Floating point answers are very fragile. A difference of only one ulp is actually pretty good. ;) There is a relevant note in: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc > On 32-bit x86 platforms when using the native code generator, the -fexcess-precision option is always on. This means that floating-point calculations are non-deterministic, because depending on how the program is compiled (optimisation settings, for example), certain calculations might be done at 80-bit precision instead of the intended 32-bit or 64-bit precision. Floating-point results may differ when optimisation is turned on. In the worst case, referential transparency is violated, because for example let x = E1 in E2 can evaluate to a different value than E2[E1/x]. > One workaround is to use the -msse2 option (see Section 4.16, ?Platform- specific Flags?, which generates code to use the SSE2 instruction set instead of the x87 instruction set. SSE2 code uses the correct precision for all floating-point operations, and so gives deterministic results. However, note that this only works with processors that support SSE2 (Intel Pentium 4 or AMD Athlon 64 and later), which is why the option is not enabled by default. The libraries that come with GHC are probably built without this option, unless you built GHC yourself. Also note I'd suspect a profound lack of interaction of that flag with ghci's bytecode interpreter. The -msse2 thing is probably doing you no good in the REPL. Also as noted above, the libraries that ship with GHC aren't build that way, so if base is doing your multiplication for you, you're probably just smacking into generated code that had -fexcess- precision turned on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 10:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 10:04:54 -0000 Subject: [GHC] #9305: GHC panic when deriving Functor on a Fixed type In-Reply-To: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> References: <054.53e1a479dcd953d35f31a779ddf295af@haskell.org> Message-ID: <069.6920a48eab16e469251578025710725f@haskell.org> #9305: GHC panic when deriving Functor on a Fixed type ---------------------------------------+---------------------------------- Reporter: andreyLevushkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: T9305 | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by andreyLevushkin): Yes, appears to be fixed in 7.8.3. I get the same output as you. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 10:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 10:55:40 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * In-Reply-To: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> References: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> Message-ID: <063.fac5bca06ae93c0a30873910263ba505@haskell.org> #9301: Rank-2 constraints are assigned kind * -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Ooops, just repeated this experiment with 7.9.20140712 and now I get: {{{ strangelet.hs:3:16: Illegal constraint: forall t. Num t In the type signature for ?strangelet?: strangelet :: (forall t. Num t) => () Failed, modules loaded: none. }}} So that type gets rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 10:55:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 10:55:54 -0000 Subject: [GHC] #5757: zero unexpected failures on all tier 1 platforms In-Reply-To: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> References: <047.3b6881d640a4e0fd41999b488e43799d@haskell.org> Message-ID: <062.ae04544ae59c8112bd92ab195a2f25e8@haskell.org> #5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: Test Suite | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5785 -------------------------------------+------------------------------------ Comment (by jrp): Here's are the results from Mac OS X https://ghc.haskell.org/trac/ghc/ticket/9286 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 11:08:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 11:08:22 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" In-Reply-To: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> References: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> Message-ID: <060.f5dfa514c4b1838321f87a4e3bfab7d7@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ---------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by mietek): * status: closed => new * resolution: duplicate => Comment: Still an issue in 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 11:08:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 11:08:41 -0000 Subject: [GHC] #9174: Haddock fails with "Module defined in multiple files" In-Reply-To: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> References: <045.7b388517426ffff02e3552a19cb548c4@haskell.org> Message-ID: <060.aea781d6e56ea1f75afa2b89b0ac2f97@haskell.org> #9174: Haddock fails with "Module defined in multiple files" ---------------------------------+---------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by mietek): * version: 7.8.2 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 11:18:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 11:18:24 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * In-Reply-To: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> References: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> Message-ID: <063.e9010501f394c9bf330414fd976fafe8@haskell.org> #9301: Rank-2 constraints are assigned kind * -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by heisenbug): * status: new => closed * resolution: => duplicate Comment: This very much looks like a duplicate of #9196, closing. But my point is that I'd like to have polymorphic (multiparameter) constraints, where the param universally abstracted over is a non-`*` kind, that is an ADT. See: {{{ class Foo a where ... data Bar (b :: Bool) x = ... instance Foo (Bar True x) where ... instance Foo (Bar False x) where ... test :: (forall b. Foo (Bar b x)) =>... }}} Here the `forall` condition is satisfiable, as all `Bool` alternatives are covered with `instance` declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 11:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 11:20:26 -0000 Subject: [GHC] #9196: Higher-rank constraint treated as type instead In-Reply-To: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> References: <047.c4cad0da526fbe474f81b1fd5a8f7a17@haskell.org> Message-ID: <062.fab28ccad51778633508cb9a227071f6@haskell.org> #9196: Higher-rank constraint treated as type instead ------------------------------------------------+-------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T9196 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: 9301 ------------------------------------------------+-------------------------- Changes (by heisenbug): * related: => 9301 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 11:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 11:27:36 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.512f0f6c22dd3f9339b652b44a331db0@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------ Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by heisenbug): * cc: ggreif@? (added) Comment: Copying a use-case from #9196: My point is that I'd like to have polymorphic (multiparameter) constraints, where the param universally abstracted over is a non-`*` kind, that is an ADT. See: {{{ class Foo a where ... data Bar (b :: Bool) x = ... instance Foo (Bar True x) where ... instance Foo (Bar False x) where ... test :: (forall b. Foo (Bar b x)) =>... }}} Here the `forall` condition is satisfiable, as all `Bool` alternatives are covered with `instance` declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 12:55:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 12:55:11 -0000 Subject: [GHC] #9307: wave4main in nofib fails Message-ID: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> #9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: MacOS X Keywords: wave4main | Type of failure: Incorrect result Architecture: x86_64 (amd64) | at runtime Difficulty: Unknown | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS. {{{ HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== wave4main: size of wave4main follows... __TEXT __DATA __OBJC others dec hex 4091904 450560 0 4295947176 4300489640 1005443a8 ==nofib== wave4main: time to run wave4main follows... ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; real 0m0.217s user 0m0.191s sys 0m0.011s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.197s user 0m0.186s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.190s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.200s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 make: *** [runtests] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 14:03:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 14:03:57 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm Message-ID: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm ------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 14:05:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 14:05:35 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.700a5da52416b1d30ca81a850b7dcccd@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm --------------------------------------------+------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.8.3 Resolution: | Keywords: fannkuch- Operating System: MacOS X | redux Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: fannkuch-redux | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by jrp): * component: Compiler => NoFib benchmark suite * testcase: => fannkuch-redux * failure: None/Unknown => Runtime performance bug * version: 7.8.2 => 7.8.3 * architecture: Unknown/Multiple => x86_64 (amd64) * keywords: => fannkuch-redux * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 17:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 17:03:17 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.8cd80f46faf15d2c66294c1d9bc8c6d3@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): @ekmett: I do agree that expecting consistency is a hard sell; but I think this particular case is a real bug on 32-bit Linux. @carter: I think you are spot on that the Linux 32-bit version is doing something funky, and producing garbage as a result. I've used an infinite precision calculator to compute the result of the multiplication. The real answer is -10.9999999999999806. It turns out that this gets rounded to -10.99999999999998 when run on Mac/Linux-64 bit; which I have not double-checked, but I am willing to think is the correct rounding with the default rounding mode of round-nearest-even. At least it looks reasonable without looking at individual bits of the lower order, and I've also some indirect evidence to this, as the failing test case came from an interaction with the Z3 SMT solver, which provided a model for a problem that turned out to be false in the 32-bit Linux realm. (The test passes on 64-bit Mac.) However, on Linux-32 bit, I get the following result: 10.999999999999982 for the multiplication. That clearly is incorrectly rounded, even if the intermediate result is taken to be infinitely precise. Thus, this leads me to think that the 32-bit linux implementation is buggy somehow. I think Carter's earlier experiment suggests 64-bit works just file (both Mac and Linux), and we have evidence that the result in 32-bit Linux is buggy. I have no way of getting to a 32-bit Mac with a modern GHC at least; but if someone can replicate it there, it would provide more evidence if this is a true 32-bit issue; or if Linux plays a role too. This may not be a huge deal, as the 32-bit machines are becoming more and more obsolete, but we should not cop-out behind floating-point inconsistencies by saying "whatever happens happens." I think Haskell has to play a leading role here and 'Double' should really mean IEEE754 64-bit double-precision value regardless of the architecture; but that's whole another can of worms, obviously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 17:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 17:50:23 -0000 Subject: [GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation In-Reply-To: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> References: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> Message-ID: <066.0cd116b66cb32dc8e6d9f23b621bf8bd@haskell.org> #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ---------------------------------+------------------------------------ Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: ios Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8300 Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by rwbarton): * blockedby: => 8300 Comment: Currently the LLVM backend doesn't actually split objects anyways: see #8300. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 18:40:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 18:40:25 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.026cd629e6712d0dca437370c37118a9@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): @lerkok, why is it "clearly incorrectly rounded"? I'm having trouble believing that claim. It could simply be that the way your input literals are encoded with more bits of precision in the x87 case. could you please try doing the original program as a self contained program like {{{ module Main where main = do x <- return ((-4.4)::Double) y <- return ((2.4999999999999956):: Double) putStrLn $ show $ decodeFloat (x*y) }}} compile with {{{ ghc main.hs -o -msse2 -fforce-recomp ; ./main ; ghc main.hs -o -fexcess- precision -fforce-recomp ; ./main }}} and tell us if theres a difference in the output in those two cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 19:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 19:56:29 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.30271b096e69deb3e9f84184c1d59131@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): @carter: Good point; I haven't considered the implications of encoding of the input literals. Nonetheless, the experiment you suggested prints precisely the same results: {{{ [ubuntu-VirtualBox]~/precision>ghc main.hs -o main -msse2 -fforce-recomp ; ./main ; ghc main.hs -o main -fexcess-precision -fforce-recomp; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) }}} which still differ from the behavior on 64-bit platforms. So, I'm still inclined to think something is off here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 19:59:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 19:59:11 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.c70e74dcd3a71432b0e468b701a82f78@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): Another point: The calls for `decodeFloat x` and `decodeFloat y` where `x` and `y` are the multiplicand and the multiplier in question return exactly the same results on both 32-bit linux and 64-bit mac; which suggest the encoding of the inputs is not to blame here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 21:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 21:01:44 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.c9777ad2c82d3983fc0b36c45d9cf816@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): ok, lets try again a different way! {{{ {-# LANGUAGE MagicHash #-} module Main where import GHC.Types import GHC.Prim main = do x <- return ((-4.4)::Double) y <- return ((2.4999999999999956):: Double) putStrLn $ show $ decodeFloat (myTimes x y) {-# NOINLINE myTimes#-} myTimes (D# a) (D# b) = D# res where res = a *## b }}} If the results are the same, then the culprit is decodeFloat, not the floating point arithmetic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 21:05:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 21:05:40 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.6da5f967a9a906b103567329b96d3815@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): woops, you did -o rather than -O ! could you do the version thats in the edit of my comment please :) (just in case) Replying to [comment:11 lerkok]: > @carter: Good point; I haven't considered the implications of encoding of the input literals. Nonetheless, the experiment you suggested prints precisely the same results: > > {{{ > [ubuntu-VirtualBox]~/precision>ghc main.hs -o main -msse2 -fforce-recomp ; ./main ; ghc main.hs -o main -fexcess-precision -fforce-recomp; ./main -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 21:43:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 21:43:30 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.ba93313d1afaa5eabe317c7a98a1fc56@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): @carter: Ah, that's better! With "-O", I get the correct result. (i.e., the one that matches the Mac.) In fact, no other flags needed. With "-O" I get the correct behavior; regardless of -msse2/-fexcess-precision, and without "-O" I get the incorrect one. So, when compiled with optimizations it's correct, but not without? I'm not sure what to make of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:05:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:05:28 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.ee9bc64ce7a9a1c565e36145c3092a62@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): did you include the force recomp flag?! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:07:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:07:28 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.bf5832ad6cb82706865a254d60fc428d@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): yes.. (just double-checked now to make double-sure!) optimization considered harmful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:13:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:13:48 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.b08640296b62ae17be19d96529037b71@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): ok good :) could you test the MagicHash version i linked to also please? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:20:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:20:30 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.a3ed9ec42ba82a807baf0c4b8f1e6c48@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): The magic hash version produces the incorrect result, with or without -O -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:23:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:23:13 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.fa2dcdb9877853092c6ea3c95f3c1575@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): could you paste the command AND the results? Its hard to know precisely which you mean eg {{{ $ shell command $results }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:25:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:25:17 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.f749b517a7c87fa99f78f90eeedcb7f6@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): Sure.. Here you go: {{{ [ubuntu-VirtualBox]~/precision/magichash>cat main.hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Types import GHC.Prim main = do x <- return ((-4.4)::Double) y <- return ((2.4999999999999956):: Double) putStrLn $ show $ decodeFloat (myTimes x y) {-# NOINLINE myTimes #-} myTimes (D# a) (D# b) = D# res where res = a *## b [ubuntu-VirtualBox]~/precision/magichash>rm main.hi; rm main.o; ghc main.hs -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) [ubuntu-VirtualBox]~/precision/magichash>rm main.hi; rm main.o; ghc main.hs -msse2 -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634421,-49) [ubuntu-VirtualBox]~/precision/magichash>rm main.hi; rm main.o; ghc main.hs -fexcess-precision -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:27:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:27:41 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.8b7250a4af381ff8df68ccc93e83aa28@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): And here're the results for the original program: {{{ [ubuntu-VirtualBox]~/precision/regular>cat main.hs x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y main :: IO () main = print $ decodeFloat r [ubuntu-VirtualBox]~/precision/regular>rm main.hi; rm main.o; ghc main.hs -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) [ubuntu-VirtualBox]~/precision/regular>rm main.hi; rm main.o; ghc main.hs -msse2 -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) [ubuntu-VirtualBox]~/precision/regular>rm main.hi; rm main.o; ghc main.hs -fexcess-precision -o main; ./main [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... (-6192449487634422,-49) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:40:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:40:04 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.930be28a3b5f44e200f024b7368091bf@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Could you please run the exact command I asked about earlier, exactly please :-) I've been traveling all day, I'll try to spin up a 32bit vm later -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 22:45:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 22:45:37 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.cb019cfdbf91ba51d27ca5edb68b8cbe@haskell.org> #9304: Floating point woes; Different behavior on Mac vs Linux -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): @carter: I lost track of what to run on what program.. it might be easiest if you could spin up a 32bit VM; nothing really urgent on this anyhow. If you can't however, I'm happy to give it a go.. maybe we should find some other way of resolving this outside the trac so people don't get spammed on this any further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 13 23:06:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jul 2014 23:06:40 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 (was: Floating point woes; Different behavior on Mac vs Linux) In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.7f670367b0496d6524e49b76bf9a1c06@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * priority: high => normal Comment: The optimizer is constant-folding the multiplication in Carter's first test program, but not the second (thanks to NOINLINE). The one mystery to me is why this constant folding is apparently performed using 64-bit floating point while multiplication in GHCi is apparently performed using 80-bit floating point. Edward's comments explain the rest of the observed behavior. You can see the same behavior in C: {{{ #include int main(void) { double x, y; x = -4.4; y = 2.4999999999999956; printf("%.30lf\n", x*y); return 0; } }}} {{{ rwbarton at morphism:/tmp/fp$ gcc -m32 mul.c -o mul rwbarton at morphism:/tmp/fp$ ./mul -10.999999999999982236431605997495 rwbarton at morphism:/tmp/fp$ gcc -m64 mul.c -o mul rwbarton at morphism:/tmp/fp$ ./mul -10.999999999999980460074766597245 }}} The Haskell Report makes no guarantee that Double is even IEEE floating- point arithmetic of any kind, and GHC's behavior is documented: https://www.haskell.org/ghc/docs/7.6.1/html/users_guide/bugs.html#bugs- ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 00:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 00:10:05 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.b8d00b1b02c94871126fbb04b8da54cd@haskell.org> #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by amurrayc): I have the same problem on iOS (simulator or device) with 7.8.2 or 7.8.3 compiled from source tarballs. I'm not sure if it should be a separate ticket. I don't think this is an `Integer` to `Float` problem per se. If I run {{{ print (F# 29.0#) -- to pick a value at random }}} I get {{{ 2109.0 }}} as in the original ticket. This should be using a direct `Float` literal, no? A little digging showed that {{{ print (floor (29.0 :: Float) :: Int) }}} shows {{{ 2109 }}} with no optimisation, but {{{ 29 }}} with `-O` Another clue is that `floor :: Float -> Integer` doesn't give the correct result, even with `-O`. Optimised `floor :: Float -> Int` uses the primop `float2Int#` while its unoptimised version and both versions of `floor :: Float -> Integer` use `decodeFloat_Int#` as does `show :: Float -> String` which last explains the original ticket. running {{{ let (m,e) = decodeFloat (29.0 :: Float) mstr = printf "%#x" m putStrLn $ "(" ++ mstr ++ ", " ++ show e ++ ")" }}} gives {{{ (0x41e80000, -19) }}} instead of the correct {{{ (0xe80000, -19) }}} Notably the erroneous `0x41e80000` is the correct value for the entire bitfield of `29.0 :: Float#` rather than just the mantissa. This all suggests that the problem lies within `decodeFloat_Int#`. I looked at `__decodeFloat_Int` in `rts/StgPrimFloat.c`, even inserting a couple of `assert`s at the end to check the values for 29.0 which passed. That led me to look at `stg_decodeFloatzuIntzh` in `rts/PrimOps.cmm` but at that point I was getting a bit lost. Any ideas anyone? For the record I'm running the above snippets in a simple Haskell `Main.hs` like: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign import Text.Printf ( printf ) foreign import ccall safe "c_main" c_main :: IO () main = do let (m,e) = decodeFloat (29.0 :: Float) mstr = printf "%#x" m putStrLn $ "(" ++ mstr ++ ", " ++ show e ++ ")" c_main }}} with a skeleton Xcode 5.1.1 project and observing the results in the debug window. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 00:11:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 00:11:46 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.497be6f0b9c62a5e9fd566b17ce22441@haskell.org> #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by amurrayc): * cc: murray@? (added) * version: 7.8.1 => 7.8.3 * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 02:25:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 02:25:55 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application Message-ID: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> #9309: Regression when building the 'sizes' application ----------------------------+---------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- I have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): make_exp (App _ (Coercion _)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 03:24:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 03:24:25 -0000 Subject: [GHC] #9310: This Cleanse Ultima is very beneficial to regulate a good blood circulation Message-ID: <048.9e7094b0a01363a342941c52a7a32dce@haskell.org> #9310: This Cleanse Ultima is very beneficial to regulate a good blood circulation ------------------------------------+------------------------------------- Reporter: joerjpool | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Cleanse Ultima | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- He something that would punish if you feel something in the question is how are you actually going to do I liked it physically working mostly stress myself out our food Afghani book more than half my life when hapless seafood gumbo I have Lucy golf when Wane have you know some sushi or thought not downtown today know what more you deprive yourself the more you want be changed when you get sold week we're not moving why outtakes house days fish they still hadn't fully fused week you some two dozen times but hey it happens that I wanted to take a little bit it is not a little bit better which will find few lost five straight days %uh week yeah I want to our ERP user roughly everything you worked so hard for all anyway so if not before keep good food you know people who you are happy light snack crackers and stuff like that my skate since I people I illegal you know I was clapping her [http://cleanseultima-uk.com/ Cleanse Ultima] hands they know they're not going to be. and what any death of Natalie wasting money first off secondly it?s not Billy is not going to help you get through your weight loss process some things that hike to do was keep so I may even take don't use to the fact that I sweet potato chips actually sweet potato fries around Kasha pizza its peak but I'll be healthy so what's that me he likes me happy nasty old who was involved you don't mind any something around the time I sleep he on a healthy track remind mean my healthy lifestyle ha-ha sweet shocking video must if you see how check on the food eat some other schools that joy hey stop talking hospital all major install look back up debt but soon up today work 350 pounds on top it's not worth it if you have some see accident I just have work 18th dub step make use of your own you created movie didn't happen ask. http://cleanseultima-uk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 03:41:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 03:41:07 -0000 Subject: [GHC] #9311: This Cleanse Ultima is very beneficial to regulate a good blood circulation Message-ID: <048.8f889dca9c82dcc7baa8a31ae63ea3fd@haskell.org> #9311: This Cleanse Ultima is very beneficial to regulate a good blood circulation ------------------------------------+------------------------------------- Reporter: joerjpool | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Cleanse Ultima | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Matt's wife Rachel who simply follow the Fat Loss Factor course with her husband Rachel change the shaper for body age 38 and this is Tam 10 lost seventy four pounds of fat at the tender age up fifty you can read his first 5k race recently something that he never would have dreamed doing previously book can I guarantee you'll have the exact same results as these guys of course not everyone actually follow the steps outlined the program that's sad but it's true but with that said I can absolutely guarantee too thanks first if you follow my program you will see results pack they could even be better than what you?ve seen in this presentation second if [http://cleanseultima-uk.com/ Cleanse Ultima] you're not a 110 percent happy with the results you can keep your money and the course for free with the full fat loss factor program you get the exact system that means that matter Rachel 10 min Lori and thousands of others have your test you can change your body and your life am so incredibly confident that it will work for you that like I said earlier if for any reason you decide the Fat Loss Factor program is in for you just email me with an 8 entire week so I?ll give you a full refund and let you keep everything for free no questions asked my personal email address is Charles at Fat Loss Factor dot comwithout after johnnie I?m here with and saying in fat loss and I?m here to talk to you a little bit about getting started with dancing on fat loss a c a lot of people at the gym they go to the gym they had no idea what to do to the first thing i want to talk about today is setting goals you want to set a goal yourself doesn't matter to settle per day hope a week ago per month so boldly maybe only spot pounds a month medium was three inches off my list it can be anything any easier machinations several and try to really cheeses was it feels really good once. http://cleanseultima-uk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 03:55:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 03:55:47 -0000 Subject: [GHC] #9312: This Cleanse Ultima is very beneficial to regulate a good blood circulation Message-ID: <048.8d186fe0ac03ada34f285f8b75505524@haskell.org> #9312: This Cleanse Ultima is very beneficial to regulate a good blood circulation ------------------------------------+------------------------------------- Reporter: joerjpool | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Cleanse Ultima | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hosokawa's know you know change of this offer but you can be slow and steady changes along the way he failed don't beat yourself up 3 don't start prime yourself honestly dying for losing weight for living a healthier life sounds about eating wafers eating I'll let me see foods they don't mind me let's be real here we all dying he something that would punish if you feel something in the question is how are you actually going to do I liked it physically working mostly stress myself out our food Afghani book more than half my life when hapless seafood gumbo I have Lucy golf when Wane have you know some sushi or thought not downtown today know what more you deprive yourself the more you want be changed when you get sold week we're not moving why outtakes house days fish they still hadn't fully fused week [http://cleanseultima-uk.com/ Cleanse Ultima] you some two dozen times but hey it happens that I wanted to take a little bit it is not a little bit better which will find few lost five straight days %uh week yeah I want to our ERP user roughly everything you worked so hard for all anyway so if not before keep good food you know people who you are happy light snack crackers and stuff like that my skate since I people I illegal you know I was clapping her hands they know they're not going to be. and what any death of Natalie wasting money first off secondly it?s not Billy is not going to help you get through your weight loss process some things that hike to do was keep so I may even take don't use to the fact that I sweet potato chips actually sweet potato fries around Kasha pizza its peak but I'll be healthy so what's that me he likes me happy nasty old who was involved you don't mind any something around the time I sleep he on a healthy track remind mean my healthy lifestyle ha-ha sweet shocking video must if you see how check on the food eat some other schools that joy hey stop talking hospital all major install look back up debt but soon up. http://cleanseultima-uk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 04:53:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 04:53:36 -0000 Subject: [GHC] #9313: This Cleanse Ultima is very beneficial to regulate a good blood circulation Message-ID: <048.289392edfca2a3b8dcaa585aa42f2ec7@haskell.org> #9313: This Cleanse Ultima is very beneficial to regulate a good blood circulation ------------------------------------+------------------------------------- Reporter: joerjpool | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Cleanse Ultima | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- You really mean anything like that and is motivation you know you don?t have to necessarily even use anger is motivation because it's pretty much all tips asking how and you can use you know something positive like hell you know I want to be healthy I do great motivation to you so just find what works for you reading it video on more specific mmm things that would beat me then on definitely me that the consular and I think that another great movie dirty music you know and finding something that beneficial innovation but then also find something that keeps you going whether it's Singh result on a scale listening to awesome music while you're working out findings that keep you going even a pre-workout hit anything is good so for the next thing [http://cleanseultima-uk.com/ Cleanse Ultima] I would say and you know this is going to be more milk a morning routine or every BB routine for you guys here so first thing you want to do when you wake up is you want to take e-class warm water squeeze some lemon and hot lemon tree am fortunate an but if you don't spice land squeeze lemon in there and drink that right away and you don?t have to drink a lot if you're not answering a lot of water but I would definitely suggest starting your day with you were impossible in water with that mean to you it was going to take some of the burden of delivering your kidneys because it's filtering through so it's going to help them and a bitwas going to be stern capitalism and is get things moving for the day which is really good so first thing start. http://cleanseultima-uk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 05:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 05:42:50 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.781816127f7157b9b76dd00e1606aa32@haskell.org> #8910: cross compiling for x86_64 solaris2 ----------------------------------+---------------------------------- Reporter: maeder | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by kgardas): * status: new => infoneeded Comment: Could you be so kind and retest with latest HEAD? The commit 6da603213b097a267418d8c14cbfaf0021ac2b2c should solve the issue of x86_64-solaris2 platform but I'm not sure if also with cross-compiling since I used native compilation using SmartOS buildbot binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 06:47:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 06:47:01 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.facda0afccfacb3e78017068359097c0@haskell.org> #8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Description changed by jstolarek: Old description: > independently, a number of folks have noticed that in various ways, GHC > currently has quite a few different memory alignment related performance > problems that can have >= 10% perf impact! > > Nicolas Frisby notes > > {{{ > On my laptop, a program showed a consistent slowdown with -fdicts-strict > > I didn't find any obvious causes in the Core differences, so I turned to > Intel's Performance Counter Monitor for measurements. After trying a few > counters, I eventuall saw that there are about an order of magnitude more > misaligned memory loads with -fdicts-strict than without, so I think that > may be a significant part of the slowdown. I'm not sure if these are code > or data reads. > > Can anyone suggest how to validate this hypothesis about misaligned > reads? > > A subsequent commit has changed the behavior I was seeing, so I'm not > interested in alternatives means to determine if -fdicts-strict is > somehow at fault ? I'm just asking specifically about data/code memory > alignment in GHC and how to diagnose/experiment with it. > > }}} > > Reid Barton has independently noted > {{{ > > so I did a nofib run with llvm libraries, ghc quickbuild > > so there's this really simple benchmark tak, > https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs > it doesn't use any libraries at all in the main loop because the Ints all > get unboxed > but it's still 8% slower with quick-llvm (vs -fasm) > weird right? > > [14:36:30] could you post the asm it generates for that > function? > [14:36:49] well it's identical between the two versions > but they get linked at different offsets because some > llvm sections are different sizes > if I add a 128-byte symbol to the .text section to move > it to the same address... then the llvm libs version is just as fast > well, apparently 404000 is good and 403f70 is bad > I guess I can test other alignments easily enough > I imagine it wants to start on a cache line > but I don't know if it's just a coincidence that it > worked with the ncg libraries > that it got a good location > > for this program every 32-byte aligned address is 10+% > faster than any merely 16-byte aligned address > > and by alignment I mean alignment of the start of the > Haskell code section > haswell, sandybridge, ivy bridge, other? > dunno > I have similar results on Intel(R) Core(TM)2 Duo CPU > T7300 @ 2.00GHz > and on Quad-Core AMD Opteron(tm) Processor 2374 HE > ok > trying a patch now that aligns all *_entry symbols to 32 > bytes > > }}} > > the key point in there is that on the tak benchmark, better alignment for > the code made a 10% perf differnce on TAk on Core2 and opteron cpus! > > benjamin scarlet and Luite are speculating that this may be further > induced by Tables next to code (TNC) accidentally creating bad alignment > so theres cache line pollution / conflicts between the L1 Instruction- > cache and data-caches. > So one experiment would be to have the TNC transform pad after the table > so the function entry point starts on the next cacheline? New description: independently, a number of folks have noticed that in various ways, GHC currently has quite a few different memory alignment related performance problems that can have >= 10% perf impact! Nicolas Frisby notes {{{ On my laptop, a program showed a consistent slowdown with -fdicts-strict I didn't find any obvious causes in the Core differences, so I turned to Intel's Performance Counter Monitor for measurements. After trying a few counters, I eventually saw that there are about an order of magnitude more misaligned memory loads with -fdicts-strict than without, so I think that may be a significant part of the slowdown. I'm not sure if these are code or data reads. Can anyone suggest how to validate this hypothesis about misaligned reads? A subsequent commit has changed the behavior I was seeing, so I'm not interested in alternatives means to determine if -fdicts-strict is somehow at fault ? I'm just asking specifically about data/code memory alignment in GHC and how to diagnose/experiment with it. }}} Reid Barton has independently noted {{{ so I did a nofib run with llvm libraries, ghc quickbuild so there's this really simple benchmark tak, https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs it doesn't use any libraries at all in the main loop because the Ints all get unboxed but it's still 8% slower with quick-llvm (vs -fasm) weird right? [14:36:30] could you post the asm it generates for that function? [14:36:49] well it's identical between the two versions but they get linked at different offsets because some llvm sections are different sizes if I add a 128-byte symbol to the .text section to move it to the same address... then the llvm libs version is just as fast well, apparently 404000 is good and 403f70 is bad I guess I can test other alignments easily enough I imagine it wants to start on a cache line but I don't know if it's just a coincidence that it worked with the ncg libraries that it got a good location for this program every 32-byte aligned address is 10+% faster than any merely 16-byte aligned address and by alignment I mean alignment of the start of the Haskell code section haswell, sandybridge, ivy bridge, other? dunno I have similar results on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz and on Quad-Core AMD Opteron(tm) Processor 2374 HE ok trying a patch now that aligns all *_entry symbols to 32 bytes }}} the key point in there is that on the tak benchmark, better alignment for the code made a 10% perf differnce on TAk on Core2 and opteron cpus! benjamin scarlet and Luite are speculating that this may be further induced by Tables next to code (TNC) accidentally creating bad alignment so theres cache line pollution / conflicts between the L1 Instruction- cache and data-caches. So one experiment would be to have the TNC transform pad after the table so the function entry point starts on the next cacheline? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:08:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:08:36 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.92757785457b8f9cad0da977f03cf999@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Is this really a bug at all? As Reid says, there are no guarantees about the precision of `Double`. A difference in the least significant bit of a `Double` on 64 bit vs 32 bit seems a remarkably small divergence to me. However I don't understand Reid's comment that "the optimiser is constant- folding the multiplication". Which optimiser? The user-guide link just says that some calculations are done in 80-bit without going back to 64-bit at each intermediate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:14:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:14:37 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application In-Reply-To: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> References: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> Message-ID: <065.da841390cee322cb999ae078f90b4139@haskell.org> #9309: Regression when building the 'sizes' application ----------------------------------------------+---------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Description changed by nomeata: Old description: > I have a package on Hackage called `sizes`. It builds fine with GHC > 7.8.2, but when building with 7.8.3 I get: > > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-apple-darwin): > make_exp (App _ (Coercion _)) New description: I have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): make_exp (App _ (Coercion _)) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:22:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:22:49 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application In-Reply-To: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> References: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> Message-ID: <065.ed0003e027aedd0c273efa08766040e1@haskell.org> #9309: Regression when building the 'sizes' application ----------------------------------------------+---------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by nomeata): Just tried with GHC HEAD, not reproducible here. Did you try with 7.8.3? Maybe it is already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:24:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:24:36 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application In-Reply-To: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> References: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> Message-ID: <065.52810c0a6b6c5f3f111d76989d983334@haskell.org> #9309: Regression when building the 'sizes' application ----------------------------------------------+---------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by nomeata): Nevermind, read your version numbers wrong. Judging from a `git log`, `make_exp` comes from external core. I guess you just have to remove `-fext-core` from your Cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:27:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:27:11 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.bf2f711799f87538c80a029ca30d9a55@haskell.org> #9125: int-to-float conversion broken on ARM - 7.8.1-rc2 ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * priority: normal => highest * milestone: => 7.8.4 Comment: I have not tried to reproduce any of this, but it looks like a solid, well-characterised bug to me. Could anyone spare the time to investigate, please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:31:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:31:09 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application In-Reply-To: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> References: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> Message-ID: <065.f0a8a4bd603b95ac5182306008353275@haskell.org> #9309: Regression when building the 'sizes' application ----------------------------------------------+---------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): And indeed, after consultation, Austin removed External Core from GHC HEAD altogether, a month or two back. It was always out of date, no one was willing to give it any love, and there was no evidence of demand. You may want to consider using the GHC API instead. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:38:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:38:16 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.c2307b9bf397711588514dcf769f3850@haskell.org> #8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Comment (by simonpj): If we knew that better alignment would improve speed at the cost of binary size (something that might differ across different architectures), that would be more motivation for a flag `-fchoose-speed-over-binary-size`. Another project for someone! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:48:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:48:19 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x Message-ID: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> #9314: Huge space leak of GHC API 7.8.x ------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC API 7.8.x uses much more memory than GHC API 7.6.x. Attached two files demonstrate this: - A.hs -- Simple program using GHC API (copied from Wiki) - B.hs -- A target file, just hello world You can compile A.hs as follows: {{{ % ghc A.hs -package ghc -package ghc-paths }}} A.hs stays in 10 seconds. So, we can investigate its memory usage with the "top" command.The following is the result: {{{ Mac (64bit) Linux (64bit) GHC 7.6.3: 20MB 4MB GHC 7.8.3: 106MB 13MB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:51:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:51:07 -0000 Subject: [GHC] #9306: Crash when shifting Integers too far left In-Reply-To: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> References: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> Message-ID: <060.89278661e60fd5c39e47b57b259b148d@haskell.org> #9306: Crash when shifting Integers too far left -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): It's not clear what to do here. After all, arbitrary precision integers are supposed to be, well, arbitrary precision. If it "worked" you'd probably get a heap overflow instead. What should the maximum size of a shift be? If anyone has good ideas, go for it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:53:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:53:08 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.463f1594320dc4d76579fbdcf424e33f@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by kazu-yamamoto): From Karel Gardas: On Solaris 11 i386 (32bit binary) {{{ GHC 7.6.3 53MB (size), 44MB (RSS) GHC 7.8.2: 91MB (size), 81MB (RSS) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:53:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:53:50 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.c51cbabaf42807f19e83c5a117df83cf@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by snoyberg): * cc: michael@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:54:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:54:47 -0000 Subject: [GHC] #9301: Rank-2 constraints are assigned kind * In-Reply-To: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> References: <048.64a2b8ad4e76178720ed01f13a0d194d@haskell.org> Message-ID: <063.6e1ddd23fe4712f3155e10f91839d13f@haskell.org> #9301: Rank-2 constraints are assigned kind * -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The trouble is that I don't know how to do type inference in the presence of polymorphic constraints. It is not a small change. It would be a useful feature. I've wanted it since at least 2000 (see [http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm Derivable Type Classes]). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 07:56:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 07:56:25 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.51ef3f0ec0048b46ffa646d20e0691f4@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------ Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The trouble is that I don't know how to do type inference in the presence of polymorphic constraints. It is not a small change. It would be a useful feature. I've wanted it since at least 2000 (see [http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm Derivable Type Classes]). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:05:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:05:43 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.33175cc9b60e7adbfd6bd67616096f18@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by darchon): Do you have a `$HOME/.ghci` config file with `:set -XNoMonomorphismRestriction`? The reason I'm asking is because I'm only getting the reported error if run ghc/runghc/ghci with`-XNoMonomorphismRestriction`. Note that before 7.8.1, the monomorphism restriction was turned _on_ by default for all invocations of ghc. Starting from 7.8.1 however, the monomorphism restriction is turned _off_ by default in ghci, but left on in the other invocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:17:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:17:02 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.9eba6af304fd94ee282edfe9f623c450@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by erikd): Yes, I had `-XNoMonomorphismRestriction` in my $HOME/.ghci file. If I remove it, the problem disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:19:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:19:46 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.457ed306b27c2990292d59140868e360@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): I hate the fact that a type-system question forces us to lose a potential optimisation. But I do not know any well-typed way around this particular one. I'm absolutely not willing for the compiler to add `unsafeCoerce`s to the code! One of GHC's most unique and distinctive features is its commitment to a solidly-typed intermediate language, and I'm not willing to compromise that property. There is a long tradition in Haskell of doing things the Right Way and using the pain to drive innovation. (Monads, System FC, kind polymorphism, etc etc.) All that said, STG code is un-typed and I would be quite happy with STG- level optimisations that transformed {{{ case e of y { ... C a b -> C a b ... } =====> case e of y { ... C a b -> y ... } }}} and then commoned identical branches. (The above transformation is done in Core too, but not when the types don't match. In STG that doesn't matter.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:22:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:22:05 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.d2c2ec649220180f89ab2cef40bd8db8@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lerkok): @simonpj: I'm not sure if it's a real bug or not. There's an observed difference in behavior on 32-bit where "-O" produces a different result compared to when compiled without "-O"; and that's at least mildly disconcerting. @carter has all the context, and I think his expertise will come in handy when he gets around to spinning up a 32-bit VM and looks at it in some more detail. If he concludes this is par-for-the-course; then we can remove the ticket. I might be in the minority, but I do not think the difference in the ulp for `Double` on 64-bit vs 32-bit a remarkably small divergence.. I wish `Double` meant precisely the same thing, regardless of architecture; i.e., the 64-bit IEEE double-precision number. But I also understand that this is a minor enough concern for most Haskell users to trickle up chain of importance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:24:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:24:15 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.467ba6a315b192a50d5ec70cd2b05078@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): Fine. But please let's have a wiki page that describes the design in detail, from the user's point of view, before you start implementing anything! * Syntax * The effect on which programs are well-typed Simple is good! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:33:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:33:11 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.3af11aadd9b4d6454c95ed471b1584a3@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by nomeata): Isn?t the first part of that transformation just a case of CSE, just as done on Core? If we do this, we?d probably also want {{{ case e of y { ... C a b -> f (C a b) ... } =====> case e of y { ... C a b -> f y ... } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 08:38:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 08:38:05 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.c76fdb35a64382ff196683738536d921@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by darchon): And the above is weird. The release notes for 7.8.1 state: {{{ The monomorphism restriction is now turned off by default in GHCi. }}} So I would expect that: {{{ ghci-7.8.3 test.hs }}} and {{{ ghci-7.8.3 -XNoMonomorphismRestriction test.hs }}} Would behave the same, that is, give an error. Otherwise I don't understand the release notes. What's the difference between having the monomorphism restriction turned off by default, and running with -XNoMonomorphismRestriction? If there is a difference, this should be documented more clearly in the release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 09:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 09:49:23 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.ade54143adaf5f9c8f451e7823403a58@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Comment (by danilo2): Hello! Is there any progress regarding this issue? It was planned for ghc-7.7 and I feel it is not very hard to implement (because it only lifts checking for liberage coverage condition) - but of course I might be wrong :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 10:25:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 10:25:37 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.d20d614ab7773bc1c4e620714924606e@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: pattern Type of failure: GHC rejects valid program | synonyms Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by cactus): * owner: => cactus Comment: I have started working on adding pattern synonym signatures, in the branch `wip/T8968`. So far, it seems I will have to go with a syntax like {{{ pattern type Eq b => Single a Bool b :: Num a => T a }}} instead of {{{ pattern Eq b => Single a Bool b :: Num a => T a }}} to make parsing unambiguous between pattern synonym definitions and pattern synonym signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 10:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 10:28:53 -0000 Subject: [GHC] #8968: Type signatures for pattern synonyms (was: Pattern synonyms and GADTs) In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.fad47fb61c2f4cbb7832a6e5361f9665@haskell.org> #8968: Type signatures for pattern synonyms ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: pattern Type of failure: GHC rejects valid program | synonyms Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by cactus): * type: bug => feature request * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:00:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:00:01 -0000 Subject: [GHC] #9150: libraries/time: parseTime barfs on leading space in format string In-Reply-To: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> References: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> Message-ID: <057.afe8c407945daa3f47bdd7794d07c7b4@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string ------------------------------------------------+-------------------------- Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thomie): * cc: ashley@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:05:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:05:01 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.eada195888b5d138eb5e84f89ed9b4ec@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): Indeed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:06:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:06:27 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.7a332411e93a8a1d3dc5853c05ae8265@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by JohnWiegley): I'm seeing a problem too, with an application that builds fine using 7.6.3. When building with -O2 and 7.8.3, GHC exhausts system memory (16G) and ultimately is killed. With 7.8.3 and -O1, or with 7.6.3, it finishes. I can't paste my code here, but would be happy to try any suggestions to help isolate the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:15:30 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.62a51174bcf66ce78b3e7251d3e45f1a@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): -O2 adds `SpecConstr`, a notorious source of blow-up. Try switching it off with `-fno-spec-constr`. The `SpecConstr` blow-up needs love and attention, and I keep being too distracted. Help most welcome. I don't think it's fundamental. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:42:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:42:02 -0000 Subject: [GHC] #9272: Template Haskell doesn't support n+k patterns In-Reply-To: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> References: <042.c32e2553df5dfe4183597f1716114a44@haskell.org> Message-ID: <057.3bcf01517ddffe842f9a9a1eed401515@haskell.org> #9272: Template Haskell doesn't support n+k patterns ----------------------------------------------+---------------------------- Reporter: br1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: I agree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 11:49:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 11:49:43 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.2001b2022198de408ab0d6c68e549573@haskell.org> #6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jstolarek): Simon, I just drafted [wiki:InjectiveTypeFamilies this wiki page]. I believe it gives a pretty good description of how the syntax will work, but it doesn't give too many details about the effects on type checking. Do you want this to be somehow formalized or would examples suffice? Do you feel that something else is missing on the wiki page? > Simple is good! Are you referring to anything particular or is this just a general reminder to follow the KISS principle? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 12:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 12:23:47 -0000 Subject: [GHC] #5861: bytestring: incorrect documentation for hGetContents In-Reply-To: <050.3aee122c69ba3960d513e0c24d139b24@haskell.org> References: <050.3aee122c69ba3960d513e0c24d139b24@haskell.org> Message-ID: <065.c765e320ad3114851c9c25119e01aab5@haskell.org> #5861: bytestring: incorrect documentation for hGetContents --------------------------------------+------------------------------------ Reporter: kmcallister | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: libraries (other) | Version: Resolution: fixed | Keywords: bytestring Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Moving to [https://github.com/haskell/bytestring/pull/25 GitHub]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:00:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:00:54 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.b56f60a4a6c25e95abf31c38863280ba@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * priority: highest => high * milestone: 7.8.1 => 7.8.4 Comment: Thanks, moving to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:04:54 -0000 Subject: [GHC] Batch modify: #5108, #5188, #609, #849, #888, #1216, #1349, #1466, #1544, #1965, #2189, #3085, #3217, #3231, #3242, #3379, #3654, #3984, #4092, #4102, #4211, #4295, #4347, #4372, #4385, #4451, #4470, #4937, #5075, #5143, #5239, #5289, #5320, #5355, #5364, #5369, #5392, #5401, #5429, #5443, #5444, #5463, #5467, #5470, #5522, #5542, #5556, #5567, #5590, #5615, #5619, #5630, #5641, #5645, #5646, #5647, #5666, #5672, #5692, #5702, #5761, #5775, #5777, #5786, #5791, #5807, #5813, #5821, #5823, #5827, #5834, #5835, #5840, #5841, #5844, #5850, #5898, #5907, #5916, #5924, #5927, #5928, #5942, #5966, #5982, #5983, #5985 Message-ID: <20140714130454.AE8002406B@ghc.haskell.org> Batch modification to #5108, #5188, #609, #849, #888, #1216, #1349, #1466, #1544, #1965, #2189, #3085, #3217, #3231, #3242, #3379, #3654, #3984, #4092, #4102, #4211, #4295, #4347, #4372, #4385, #4451, #4470, #4937, #5075, #5143, #5239, #5289, #5320, #5355, #5364, #5369, #5392, #5401, #5429, #5443, #5444, #5463, #5467, #5470, #5522, #5542, #5556, #5567, #5590, #5615, #5619, #5630, #5641, #5645, #5646, #5647, #5666, #5672, #5692, #5702, #5761, #5775, #5777, #5786, #5791, #5807, #5813, #5821, #5823, #5827, #5834, #5835, #5840, #5841, #5844, #5850, #5898, #5907, #5916, #5924, #5927, #5928, #5942, #5966, #5982, #5983, #5985 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:06:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:06:09 -0000 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> References: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> Message-ID: <068.539b707e3a3d77c300037fc2d1ee0f2d@haskell.org> #3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: patch => infoneeded * milestone: 7.6.2 => 7.10.1 Comment: Moving out of patch (and to 7.10.1 anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:07:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:07:45 -0000 Subject: [GHC] Batch modify: #6016, #6047, #6079, #6087, #6113, #7045, #7105, #7316, #1498, #2401, #2614, #3052, #3184, #3372, #3427, #3462, #3464, #3483, #3517, #3547, #3559, #3588, #3619, #3625, #3632, #3645, #3649, #3699, #3701, #3704, #3712, #3713, #3739, #3744, #3753, #3755, #3766, #3767, #3782, #3786, #3844, #3869, #3881, #3895, #3903, #3937, #3946, #3980, #3990, #4016, #4019, #4020, #4048, #4049, #4052, #4081, #4096, #4101, #4105, #4114, #4121, #4140, #4150, #4162, #4176, #4180, #4213, #4215, #4222, #4281, #4288, #4296, #4301, #4308, #4316, #4329, #4340, #4366, #4413, #4428, #4429, #4440, #4442, #4453, #4459, #4466, #4471, #4479, #4505, #4520, #4800, #4806, #4815, #4823, #4824, #4831, #4833, #4836, #4837, #4861, #4896, #4899, #4913, #4921, #4931, #4938, #4942, #4955, #4960, #4980, #5014, #5016, #5059, #5062, #5073, #5140, #5142, #5158, #5171, #5190, #5197, #5202, #5219, #5224, #5248, #5251, #5262, #5266, #5267, #5273, #5288, #5291, #5292, #5296, #5298, #5302, #5305, #5326, #5333, #5376, #5378, #5387, #5388, #5495, #5537, #5608, #5654, #5918, #5959, #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2104, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2526, #2530, #2531, #2550, #2598, #2600, #2640, #2641, #2642, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2836, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3003, #3055, #3061, #3065, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3191, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3376, #3452, #3458, #3470, #3509, #3533, #3543, #3571, #3646, #3711, #3771, #3781, #3859, #3870, #3960, #4017, #4022 Message-ID: <20140714130745.5C9FD2406B@ghc.haskell.org> Batch modification to #6016, #6047, #6079, #6087, #6113, #7045, #7105, #7316, #1498, #2401, #2614, #3052, #3184, #3372, #3427, #3462, #3464, #3483, #3517, #3547, #3559, #3588, #3619, #3625, #3632, #3645, #3649, #3699, #3701, #3704, #3712, #3713, #3739, #3744, #3753, #3755, #3766, #3767, #3782, #3786, #3844, #3869, #3881, #3895, #3903, #3937, #3946, #3980, #3990, #4016, #4019, #4020, #4048, #4049, #4052, #4081, #4096, #4101, #4105, #4114, #4121, #4140, #4150, #4162, #4176, #4180, #4213, #4215, #4222, #4281, #4288, #4296, #4301, #4308, #4316, #4329, #4340, #4366, #4413, #4428, #4429, #4440, #4442, #4453, #4459, #4466, #4471, #4479, #4505, #4520, #4800, #4806, #4815, #4823, #4824, #4831, #4833, #4836, #4837, #4861, #4896, #4899, #4913, #4921, #4931, #4938, #4942, #4955, #4960, #4980, #5014, #5016, #5059, #5062, #5073, #5140, #5142, #5158, #5171, #5190, #5197, #5202, #5219, #5224, #5248, #5251, #5262, #5266, #5267, #5273, #5288, #5291, #5292, #5296, #5298, #5302, #5305, #5326, #5333, #53 76, #5378, #5387, #5388, #5495, #5537, #5608, #5654, #5918, #5959, #344, #602, #1012, #1016, #1330, #1365, #1377, #1379, #1420, #1534, #1572, #1574, #1600, #1612, #1631, #1693, #1727, #1820, #1853, #1880, #1883, #1885, #1894, #2028, #2064, #2075, #2104, #2119, #2123, #2135, #2140, #2147, #2159, #2168, #2215, #2224, #2256, #2258, #2260, #2269, #2273, #2289, #2333, #2340, #2345, #2346, #2365, #2370, #2374, #2387, #2437, #2439, #2459, #2460, #2514, #2522, #2526, #2530, #2531, #2550, #2598, #2600, #2640, #2641, #2642, #2710, #2721, #2731, #2737, #2776, #2803, #2805, #2836, #2867, #2933, #2940, #2945, #2946, #2950, #2968, #2986, #2988, #2991, #3000, #3003, #3055, #3061, #3065, #3070, #3073, #3107, #3122, #3123, #3138, #3140, #3191, #3192, #3238, #3251, #3282, #3314, #3321, #3351, #3355, #3376, #3452, #3458, #3470, #3509, #3533, #3543, #3571, #3646, #3711, #3771, #3781, #3859, #3870, #3960, #4017, #4022 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:11:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:11:08 -0000 Subject: [GHC] Batch modify: #4012, #4245, #5539, #5620, #5642, #5763, #5859, #5954, #6166, #7103, #7277 Message-ID: <20140714131108.602AE2406B@ghc.haskell.org> Batch modification to #4012, #4245, #5539, #5620, #5642, #5763, #5859, #5954, #6166, #7103, #7277 by thoughtpolice: priority to normal Comment: Lowering priority (these tickets are assigned to older versions, so they're getting bumped as they've been around for a while). -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:12:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:12:11 -0000 Subject: [GHC] Batch modify: #7320, #7325, #4012, #4245, #5539, #5620, #5642, #5763, #5859, #5954, #6166, #7103, #7243, #7277, #7388, #2648 Message-ID: <20140714131211.984172406B@ghc.haskell.org> Batch modification to #7320, #7325, #4012, #4245, #5539, #5620, #5642, #5763, #5859, #5954, #6166, #7103, #7243, #7277, #7388, #2648 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:40:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:40:37 -0000 Subject: [GHC] #5051: Typechecker behaviour change In-Reply-To: <044.569620fef33303d8ae9785181226236d@haskell.org> References: <044.569620fef33303d8ae9785181226236d@haskell.org> Message-ID: <059.888b275adcd2c6cee25bb7054c5aa924@haskell.org> #5051: Typechecker behaviour change -------------------------------------------------+------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 7.10.1 Resolution: | Version: 7.0.2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T5051 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * priority: high => normal * milestone: => 7.10.1 Comment: Lowering priority (this has been open for a while). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:42:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:42:53 -0000 Subject: [GHC] Batch modify: #8131, #7011, #7763, #7836, #7987, #8013, #8014, #8093, #8097, #8406, #8798, #8910, #9092, #8115, #9142, #9198, #9221, #9267, #9268, #703, #2408, #7673, #7955, #7983, #7984 Message-ID: <20140714134253.04D712406B@ghc.haskell.org> Batch modification to #8131, #7011, #7763, #7836, #7987, #8013, #8014, #8093, #8097, #8406, #8798, #8910, #9092, #8115, #9142, #9198, #9221, #9267, #9268, #703, #2408, #7673, #7955, #7983, #7984 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:45:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:45:00 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.d2cf2291dbf619eb53c66b6f7e4c7e5b@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | 7.10.1 Operating System: Unknown/Multiple | Version: Type of failure: Runtime performance bug | 7.8.1-rc2 Test Case: | Keywords: simplCore/should_compile/T8832 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:45:05 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.2847a40c561f2791178ea228d5411667@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:58:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:58:14 -0000 Subject: [GHC] #8626: Bad magic. Expected: feedfacf, got: feedface In-Reply-To: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> References: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> Message-ID: <059.d8f541f3db2b9d64c75c8b1963c62ff3@haskell.org> #8626: Bad magic. Expected: feedfacf, got: feedface -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => infoneeded Comment: Hi, do you have any information on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:58:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:58:22 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.f4b002ab2aa79101486319de822d30e0@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:58:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:58:27 -0000 Subject: [GHC] #8626: Bad magic. Expected: feedfacf, got: feedface In-Reply-To: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> References: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> Message-ID: <059.0732c9a2545af78a273cdf757309de60@haskell.org> #8626: Bad magic. Expected: feedfacf, got: feedface -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:58:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:58:38 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.a20f75c8623cc97cfa22d786f3475096@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:59:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:59:33 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.6f646eca7de59d57b9bce753004a10e8@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 13:59:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 13:59:57 -0000 Subject: [GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks In-Reply-To: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> References: <044.9e43150f2d22b2782c0ffcb891a3cae9@haskell.org> Message-ID: <059.895a16dd59d5b2a3fe98d1f54a5b8e6d@haskell.org> #8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8480 ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 Comment: Moving to 7.10, as there's still stuff to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:01:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:01:03 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.abfa13ce671ebecc67bd83cd878987c5@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------ Reporter: joeyadams | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: ekmett (added) * status: new => patch * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:15:27 -0000 Subject: [GHC] #9306: Crash when shifting Integers too far left In-Reply-To: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> References: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> Message-ID: <060.43c3351393944fd90ce1ad9f33c3b0dd@haskell.org> #9306: Crash when shifting Integers too far left -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:2 dfeuer]: ...just a minor nit-pick about the code-example: {{{ Literal 100000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:19:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:19:57 -0000 Subject: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators In-Reply-To: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> References: <057.b2c48f6dcee48c8d27365f9afce8a850@haskell.org> Message-ID: <072.9f007cc04c532b039c6d6591f08f178a@haskell.org> #5108: Allow unicode sub/superscript symbols in both identifiers and operators ---------------------------------------+----------------------------------- Reporter: mikhail.vorozhtsov | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: 7.1 Resolution: | Keywords: lexer unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by mikhail.vorozhtsov): Here is the [http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/24760 link] to the discussion. I came up with a proposal that avoids the whole "primes on operators" thing for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:25:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:25:34 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 Message-ID: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> #9315: Weird change in allocation numbers of T9203 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to improve our handle on allocation numbers, I?m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I?m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:38:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:38:48 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.acc49815cccf0cb4f84234761175bf78@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * priority: normal => high * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:52:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:52:42 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.a5389cd75278d21bc1696d6d452cfcd8@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonpj): * owner: => simonmar Comment: This looks like #9155 again, but Simon M fixed it, and the fix was merged. Simon M will look again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 14:54:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 14:54:22 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.9fcd459bbbb043627fb8bd2c42bb2e1b@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp ---------------------------------------+---------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler (NCG) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 15:17:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 15:17:09 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.40e2547369c3e9bda9dc4753bfe97038@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:26 simonpj]: > However I don't understand Reid's comment that "the optimiser is constant-folding the multiplication". Which optimiser? I mean the rule {{{ primOpRules nm DoubleMulOp = mkPrimOpRule nm 2 [ binaryLit (doubleOp2 (*)), ... ] }}} which we can see firing by compiling with `-ddump-rule-firings`: {{{ ... Rule fired: *## ... }}} The constant folder represents literal Double values with Rational, but (unless excess precision is enabled) truncates the result of each operation by converting to Double and back, so it should match the answer obtained by using 64-bit Double throughout, as it does in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 15:23:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 15:23:24 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM (was: int-to-float conversion broken on ARM - 7.8.1-rc2) In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.9fb76856aa235773bf03ffc2eb777b8f@haskell.org> #9125: int-to-float conversion broken on ARM ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 15:40:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 15:40:09 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.2c64587b19f48087ad701c50a9d72dc8@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: ghci/scripts/T9086b, | Related Tickets: ghc-e/should_run/T9086 | Blocking: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * testcase: => ghci/scripts/T9086b, ghc-e/should_run/T9086 Comment: So, can we close this ticket? It looks as if everyone thinks it's done. I added the test cases to the ticket description. I'll make it highest priority so we don't forget to close it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 15:52:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 15:52:31 -0000 Subject: [GHC] #9279: Optimisation bug In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.1054421c0e57f8fc7c939766df43a131@haskell.org> #9279: Optimisation bug --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): So how do I reproduce this? I get {{{ simonpj at cam-05-unx:~/tmp/T9279$ ghc -O2 Haxl/Core/Monad.hs Haxl/Core/Types.hs:66:8: Could not find module ?Data.Aeson? Perhaps you meant Data.Version (from base) Use -v to see a list of the files searched for. Haxl/Core/Types.hs:67:8: Could not find module ?Data.Hashable? Use -v to see a list of the files searched for. Haxl/Core/Types.hs:72:8: Could not find module ?Data.HashMap.Strict? Perhaps you meant Data.IntMap.Strict (from containers-0.5.5.1) Data.Map.Strict (from containers-0.5.5.1) Use -v to see a list of the files searched for. Haxl/Core/Monad.hs:73:8: Could not find module ?Control.Concurrent.STM? Perhaps you meant Control.Concurrent.QSem (from base) Control.Concurrent (from base) Control.Concurrent.Chan (from base) Use -v to see a list of the files searched for. }}} Also can you try with `-ddump-inlinings -dverbose-core2core -ddump-occur- anal` and add the log file? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 15:55:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 15:55:10 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.6aab331bf293f98a2a1caa210881a81c@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions --------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonpj): Sounds fantastic to me. Do please document the design so that others do not later accidentally slip back into calling allocating functions! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 17:17:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 17:17:58 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.c0404e4e507037b65a4d86d95a72b847@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 9276 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): @lerkok I think @rwbarton has the problem nailed. If I'm understanding everything correctly, the culprit here is that GHC's const evaluation tooling doesn't respect the implicit floating point model induced by -msse2 vs -f-excess-precision ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 18:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:30:45 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.8b2a20eec7a46fc0623f9a219e78213c@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Comment (by goldfire): See https://phabricator.haskell.org/D69 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 18:36:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:36:10 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.4d42fc386b1af76a064ee436c148311e@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Comment (by goldfire): I take back my claim that `-XDysfunctionalDependencies` cannot cause type errors. While it's true that fundeps do not exist in Core, it's conceivable that dysfundeps could cause invalid Core to be produced, leading to errors caught by `-dcore-lint`. I have not thought this out in great detail, but I think I was too quick to judgment in comment:7. To summarize: it's possible that dysfundeps are type-safe, and it's possible that they are not. I have not thought hard enough about the problem to stake a claim on one answer or another: my reasoning in comment:7 is bogus, though perhaps my conclusion is correct. In any case, I don't wish to be cited as the person who thinks that these are safe! :) I still ''do'' think that, if someone discovers these ''are'' safe, they might become an interesting tool. -- Ticket URL: GHC The Glasgow Haskell Compiler From erkokl at gmail.com Mon Jul 14 18:45:03 2014 From: erkokl at gmail.com (Levent Erkok) Date: Mon, 14 Jul 2014 11:45:03 -0700 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <060.c0404e4e507037b65a4d86d95a72b847@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> <060.c0404e4e507037b65a4d86d95a72b847@haskell.org> Message-ID: @carter: Yes; I think @rwbarton is quite right in his analysis! @rwbarton: Thanks for nailing this one! I'd consider this a bug; but I'm not sure how important it is to reserve cycles. @simonpj can definitely make that call. Maybe it can be merged with @carter's ticket #9276, and addressed within that context. On Mon, Jul 14, 2014 at 10:17 AM, GHC wrote: > #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 > -------------------------------------+------------------------------------ > Reporter: lerkok | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.3 > Resolution: | Keywords: floating point > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: 9276 > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by carter): > > @lerkok I think @rwbarton has the problem nailed. > > If I'm understanding everything correctly, the culprit here is that GHC's > const evaluation tooling doesn't respect the implicit floating point model > induced by -msse2 vs -f-excess-precision ? > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Mon Jul 14 18:46:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:46:54 -0000 Subject: [GHC] #9086: main :: IO Int does different things with runghc and when compiled In-Reply-To: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> References: <042.36569005b1f8b3aeab2d4ddcc4b347ed@haskell.org> Message-ID: <057.cc3820b737c0b1923999a310db2c8f11@haskell.org> #9086: main :: IO Int does different things with runghc and when compiled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gintas Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: ghci/scripts/T9086b, | Related Tickets: ghc-e/should_run/T9086 | Blocking: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Eh, yes, guess my habit of closing stuff with `fixes #n` in the commit message came through. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 18:50:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:50:08 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.914c80a7460e48ddf41813cf85b39f1c@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------ Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Phabricator and SPJ also have the higher number. If noone else can reproduce 42946176 I guess I?ll change it back. But I still don?t get it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 18:52:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:52:32 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.8ac1348f4c698bf4d5f0ae6371a702ad@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------ Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Ah, Austin already reverted it in changeset:4690466de2249fd73600567bd90d462ac26b2d1c/ghc. But sure enough, my benchmark builder fails again... And it really is a 64bit executable, in case you think that?s it: {{{ $ file ./ghc-master/testsuite/tests/perf/should_run/T9203 ./ghc-master/testsuite/tests/perf/should_run/T9203: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7672054d3dd125700b11710744581a8ae8502766, not stripped }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 18:55:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 18:55:21 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing In-Reply-To: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> References: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> Message-ID: <063.3de63320e0b8c4bb83512f20748111f5@haskell.org> #8615: All packages built with GHC / clang are failing -------------------------------------+------------------------------------ Reporter: sylvestre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by sylvestre): The option has been implemented in LLVM and will be part of Clang 3.5: http://llvm.org/viewvc/llvm- project?diff_format=h&view=revision&revision=211756 I think this bug can be closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 19:27:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 19:27:06 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.97077bcabd86d538e28608c64639c6f3@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------ Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Next thing to try is ticky-ticky profiling. Compile with `-ticky` and run with `+RTS -rT9203.ticky` and compare output. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 20:01:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 20:01:00 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.e624ef651d08aa3ae881f0a8c8d8fb01@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") ----------------------------+---------------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1241, #2247, #8356, #9103 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by simonpj): * related: #1241, #2247, #8356 => #1241, #2247, #8356, #9103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 20:04:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 20:04:38 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.dc22daca9af55953136960e89ccdce0d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D69 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 20:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 20:44:39 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.121f301e8180e878c2b9be1aaaf91ac4@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): How did I forget about ticky ticky? Thanks for reminding! Ticky output is identical.... so it has to be in the libraries. I recompiled them with `-ticky`, and now I see some difference related to `GHC.Fingerprint.fingerprintData1`. I?m attaching both ticky reports, maybe someone can see a pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:06:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:06:47 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.ba784cfee2d394e95a08e5b2a7b10c35@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Other Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): In my case, this happens even with -O0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:16:23 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.3cc36010480697af5c9311c05c619734@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Sigh. Both `Foreign.Storable` and `GHC.Fingerprint` have (with `-dsuppress-unique`) identical core. Also `Data.Typeable.Internal` where the ticky diffs show the same number of calls to `base:Data.Typeable.Internal.$fTypeableks_$ctypeRep#`, but a different allocation count.... hah! but only when I copy the ghc invocation from one host to the other, not if if I run `make` there, which for some reason passes `-O2` when compiling `Data.Typeable.Internal`.... So the problem is as follows: Invocation of `validate` and the usual `devel2` settings in `mk/build.mk` have `GhcLibHcOpts += -O -dcore- lint`, while the default in the absence of everything is `-O2` (in `in GhcLibHcOpts=-O2`). And sometime that makes a difference... Clearly, this needs to be consolidated. What are the settings used to actually build the releases? `-O` or `-O2`? The appropriate one needs to be used in `validate`, otherwise these tests are not very useful. And then people will have to use the same flags in their `mk/build.mk` or learn to ignore benchmark results from such a tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:17:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:17:47 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.026464d6d7e54a12a902667baef9cb5e@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103 | -------------------------------------+------------------------------------- Comment (by simonpj): Provoked by this ticket, and other recent ones (#9227, #9103) I?ve taken another look. Here are my preliminary conclusions. * #1241 has the best overall discussion, and the paper ?[http://research.microsoft.com/en-us/um/people/simonpj/papers/fd-chr/ Understanding functional dependencies using constraint handling rules]? * The [http://www.haskell.org/ghc/docs/latest/html/users_guide/type- class-extensions.html#instance-rules user manual section] that claims ?Both the Paterson Conditions and the Coverage Condition are lifted if you give the `-XUndecidableInstances` flag? is plain wrong. * What actually happens is that `-XUndecideableInstances` weakens the Coverage Condition to the Liberal Coverage condition. See `Note [Coverage conditions]` in `FunDeps.lhs`. (Actually, looking at the paper, what is called ?Liberal Coverage Condition? here and in the code is the ?Refined Weak Coverage Condition? in the paper, Definition 15. * Even this looks bogus. Looking at #1241 comment 15, we see that to get good behaviour (termination, confluence) we need ?full fundeps? and ?S(tvsright) are all type variables?, neither of which are checked by GHC. * I disagree with Richard's comment above (comment 11). There is no way that fundeps can cause a program to pass the type checker but fail Core Lint. All that fundeps do is cause extra ?derived? type equalities to be added to the constraint solver?s pile. That can cause type errors, and perhaps confusing ones, but it cannot cause unsoundness. * The worst that can happen is 1. Non-termination of the type inference engine. This can definitely happen, but is acceptable; c.f. `-XUndecideableInstances`. 2. Non-confluence of type inference. The paper goes on about this at length. I think it amounts to incompleteness. Maybe type inference will succeed one day, but fail the next because of some random variation in the order in which the constraint solver tackles its constraints. I do not have an example that shows this behaviour, but it would be a Bad Thing. I see no good reason to stop programmers getting perhaps-strange behaviour if they ask for it. So I would be OK with doing this (which is exactly what https://phabricator.haskell.org/D69 proposes this behaviour for the Coverage Condition (see [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-rules user manual]) * No flags: Coverage Condition enforced * `-XUndecidableInstances`: changes Coverage Condition to Liberal Coverage Condition. This risks non-termination. I?m still uneasy about the consequences of not checking for ?full? fundeps (see comment 15 of #1241) but it?s what happens right now. * `-XDysFunctionalDependencies`: removes the Coverage Condition altogether, with somewhat unknown consequences. So this is a long-winded way of saying I?m ok with the D69 proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:20:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:20:34 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.1f3ac8aa61241420e7e6e12ab032a611@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #1241, #2247, #8356, #9103 => #1241, #2247, #8356, #9103, #9227 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:34:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:34:42 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.1f9985e78bda8c7c6a8295fa4240db6f@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): Incidentally, on the Phab comment stream, danilo2 says: I'm very attracted to the idea to be able to throw away liberage coverage condition - in some places it could give interesting effects (like IncoherentInstances). But in opposite to IncoherentInstances, I've got a real-life code, which is right now working using DysfunctionalDependencies and is working great. I and some people from the company I'm working in were thinking for a long time if we can replace a very special type class instance with other mechanisms and we came to a conclusion, that using this extension would be life saver for us - and this is the reason I started looking into ghc and implementing it. I would be very happy If you agree with me and would allow this extension to exist within GHC. I'm adding the comment in here by way of further motivation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:46:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:46:30 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.3322d9f66f3244a29c7bd2c34ae5fddc@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): As well as your last para, you seem to have found that compiling some particular module (is it `Data.Typeable.Internal`?) with -O2 instance of -O1 makes a factor of 2 difference in allocation for at least this test. Is that right? If so, it'd be worth knowing why, and perhaps putting `{-# OPTIONS_GHC -O2 #-}` with a clear comment in that file. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:49:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:49:31 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.89bcc8adee87b4ab46c64ad4657afcef@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Right, but that?s a separate issue from getting reproducible test cases, which is what I care about at the moment. The factor of two has so far only turned up in a pathetic test case, hasn?t it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:50:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:50:42 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.8fc456b802c221fb0df6e16e44d9611f@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Description changed by jrp: Old description: > While trying to improve our handle on allocation numbers, I?m stuck with > the test case T9203. On some machines, it allocates roughly 95747304 > bytes (this includes travis and my laptop), on others 42946176 bytes > (e.g. on the machine where I monitor benchmark performance). All machines > are 64 bit Linux machines. > > The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical > (up to variable names). Even `-ddump-asm` looks the same, besides some > jump target reordering. The binary runs too small to get a heap profile. > > I?m a bit stuck here: What can be the cause for these differences? > > (BTW, if have an up-to-date GHC tree, can you report the number you get? > Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) New description: While trying to improve our handle on allocation numbers, I?m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I?m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=T9203` for that.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 14 21:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jul 2014 21:55:46 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.298691738baa8fd8092cc72f8a5768be@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by jrp): I get {{{ =====> T9203(normal) 2035 of 4040 [0, 0, 0] cd ./perf/should_run && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o T9203 T9203.hs -O2 >T9203.comp.stderr 2>&1 cd ./perf/should_run && ./T9203 +RTS -V0 -tT9203.stats --machine-readable -RTS T9203.run.stdout 2>T9203.run.stderr bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected bytes allocated: 95747304 +/-5% Lower bound bytes allocated: 90959938 Upper bound bytes allocated: 100534670 Actual bytes allocated: 42946176 *** unexpected failure for T9203(normal) }}} with OS X, BuildFlavour = perf and InstallExtraPackages=YES. There are also a few other performance-related failures: {{{ Unexpected results from: TEST="T5611 T9203 T5435_dyn_asm haddock.Cabal T4801 T6048" OVERALL SUMMARY for test run started at Sun Jul 13 17:28:27 2014 BST 2:42:49 spent to go through 4040 total tests, which gave rise to 19417 test cases, of which 15712 were skipped 28 had missing libraries 3629 expected passes 42 expected failures 0 caused framework failures 0 unexpected passes 6 unexpected failures Unexpected failures: concurrent/should_run T5611 [bad stderr] (normal) perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 01:13:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 01:13:33 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.06252102e3f77b4b3f237fdec75984d1@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: floating point Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: 9276 | Related Tickets: | -------------------------------------+------------------------------------- Comment (by lerkok): @carter: Yes; I think @rwbarton is quite right in his analysis! @rwbarton: Thanks for nailing this one! I'd consider this a bug; but I'm not sure how important it is to reserve cycles. @simonpj can definitely make that call. Maybe it can be merged with @carter's ticket #9276, and addressed within that context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 02:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 02:17:40 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.8ca5997184efc3c7df0a3c94f829f5ab@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Difficulty: Unknown | at runtime Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Comment (by amurrayc): So here's a thing: On a hunch I switched the assignments of `r1` and `r2` in `stg_decodeFloatzuIntzh` so that it now reads {{{ r2 = W_[mp_tmp1]; r1 = W_[mp_tmp_w]; }}} with everything else the same. What do you know, {{{ let (m,e) = decodeFloat (29.0 :: Float) estr = printf "%#x" e putStrLn $ "(" ++ show m ++ ", " ++ estr ++ ")" }}} gives {{{ (-19, 0xe80000) }}} Does that give anyone any clues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 03:58:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 03:58:56 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.09319414657917b20447cf93eb3305c1@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Difficulty: Unknown | at runtime Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Comment (by amurrayc): I'm still learning about Cmm and calling conventions &c. so forgive my stumblings. If I modify `stg_decodeFloatzuIntzh` so that the two temporary pointers are shifted by one word the function returns the correct value. That is {{{ reserve 2 = tmp { mp_tmp1 = tmp + WDS(1); mp_tmp_w = tmp; }}} becomes {{{ reserve 3 = tmp { mp_tmp1 = tmp + WDS(2); mp_tmp_w = tmp + WDS(1); }}} With this change everything seems to work correctly. I'm confused though. The pointer that was getting clobbered by the argument value was `tmp + WDS(1)` but now `mp_tmp_w` i.e. the exponent is fine. Anyway, I hope this give someone wiser a clue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 06:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 06:57:10 -0000 Subject: [GHC] #9264: Scoped kind variables do not work with default associated types In-Reply-To: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> References: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> Message-ID: <062.25fb07098f5d9bcf0a610b5a454330b9@haskell.org> #9264: Scoped kind variables do not work with default associated types -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9b8ba62991ae22420a0c4486127a3b22ee7f22bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b8ba62991ae22420a0c4486127a3b22ee7f22bd" Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 06:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 06:57:11 -0000 Subject: [GHC] #9263: Iface type variable out of scope with default associated types and polykinds In-Reply-To: <047.8399d093a1731e650b621887335ccbf3@haskell.org> References: <047.8399d093a1731e650b621887335ccbf3@haskell.org> Message-ID: <062.8e691cf490a7a17dbf0419c0d0efa711@haskell.org> #9263: Iface type variable out of scope with default associated types and polykinds -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9b8ba62991ae22420a0c4486127a3b22ee7f22bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b8ba62991ae22420a0c4486127a3b22ee7f22bd" Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 06:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 06:57:11 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.a2c2db30e98280711185337799ed9ee9@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9b8ba62991ae22420a0c4486127a3b22ee7f22bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b8ba62991ae22420a0c4486127a3b22ee7f22bd" Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 07:20:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 07:20:59 -0000 Subject: [GHC] #9063: Default associated type instances are too general In-Reply-To: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> References: <047.e936eb0a4e7841ef41df76cc9d45adf5@haskell.org> Message-ID: <062.9057c271902c438b0eb8791051174084@haskell.org> #9063: Default associated type instances are too general -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: polykinds/T9063 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9063 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 07:21:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 07:21:31 -0000 Subject: [GHC] #9264: Scoped kind variables do not work with default associated types In-Reply-To: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> References: <047.d64d3bd9c643c1dc0b12542fe4016995@haskell.org> Message-ID: <062.f3d47a8eeb10806545979b2cf80563a5@haskell.org> #9264: Scoped kind variables do not work with default associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: polykinds/T9264 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9264 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 07:21:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 07:21:51 -0000 Subject: [GHC] #9263: Iface type variable out of scope with default associated types and polykinds In-Reply-To: <047.8399d093a1731e650b621887335ccbf3@haskell.org> References: <047.8399d093a1731e650b621887335ccbf3@haskell.org> Message-ID: <062.3847ea248d7386fc98fa085662388c2e@haskell.org> #9263: Iface type variable out of scope with default associated types and polykinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: polykinds/T9063 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T9063 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 08:08:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 08:08:28 -0000 Subject: [GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints Message-ID: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The following code fails to compile under GHC 7.8.3: {{{ {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module SingletonsBug where import Control.Applicative import Data.Constraint (Dict(..)) import Data.Singletons import Data.Singletons.TH (singletons) import Data.Traversable (for) $(singletons [d| data SubscriptionChannel = BookingsChannel |]) type family T (c :: SubscriptionChannel) :: * type instance T 'BookingsChannel = Bool witnessC :: SSubscriptionChannel channel -> Dict (Show (T channel), SingI channel) witnessC SBookingsChannel = Dict forAllSubscriptionChannels :: forall m r. (Applicative m) => (forall channel. (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r forAllSubscriptionChannels f = withSomeSing BookingsChannel $ \(sChannel) -> case witnessC sChannel of Dict -> f sChannel }}} {{{ SingletonsBug.hs:38:15: Could not deduce (SingI channel0) arising from a use of ?f? from the context (Applicative m) bound by the type signature for forAllSubscriptionChannels :: Applicative m => (forall (channel :: SubscriptionChannel). (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r at SingletonsBug.hs:(32,6)-(34,8) or from ((Show (T a), SingI a)) bound by a pattern with constructor Dict :: forall (a :: Constraint). (a) => Dict a, in a case alternative at SingletonsBug.hs:38:7-10 The type variable ?channel0? is ambiguous Note: there is a potential instance available: instance SingI 'BookingsChannel -- Defined at SingletonsBug.hs:19:3 In the expression: f sChannel In a case alternative: Dict -> f sChannel In the expression: case witnessC sChannel of { Dict -> f sChannel } SingletonsBug.hs:38:17: Couldn't match type ?channel0? with ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: Sing a -> m r at SingletonsBug.hs:(36,3)-(38,24) Expected type: SSubscriptionChannel channel0 Actual type: Sing a Relevant bindings include sChannel :: Sing a (bound at SingletonsBug.hs:36:36) In the first argument of ?f?, namely ?sChannel? In the expression: f sChannel }}} However, this works fine in GHC 7.8.2. If I change one line to this: {{{ withSomeSing BookingsChannel $ \(sChannel :: SSubscriptionChannel c) -> }}} The code compiles in GHC 7.8.3. Another change that doesn't require a type signature (but changes the program) is to change that constraint from: {{{ Show (T channel), SingI channel }}} to just {{{ SingI channel }}} It seems that the use of the type family breaks the inference, but this might be a bit of a red herring! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 08:12:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 08:12:43 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.a9c4a12ac53bcc31ce1c7a1f86f7f1be@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): It's fine actually. * GHCi maintains two sets of flags, one for the interactive REPL and one for loading module (see [http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-set.html #ghci-interactive-options the manual 2.8.3]). * The interactive flags has `-XNoMonomorphismRestriction` applied ''after'' initialising from the .ghci file. * The release notes mean that only the interactive flags have `-XNoMonomorphismRestriction`. The loading flages are unaffected. I'll clarify the documentation which isn't great I agree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 08:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 08:18:18 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.fa8eb39bd68a0fe29c3ed20b8e443eb7@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d76165412a07f57bc21e3d7ac42ef9ea231d04e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d76165412a07f57bc21e3d7ac42ef9ea231d04e2" Improve documentation of :set/:seti Prompted by Trac #9299 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 08:18:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 08:18:50 -0000 Subject: [GHC] #9299: GHCi type inference error In-Reply-To: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> References: <044.ed1e9117e0a53bd4716825cc26f74899@haskell.org> Message-ID: <059.2f738811e7bcdd043573e1bd8275344e@haskell.org> #9299: GHCi type inference error -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 10:40:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 10:40:00 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid Message-ID: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Easy (less Blocking: | than 1 hour) | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 10:42:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 10:42:43 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.bf89491c1749dbeb0e2f7c78fcb3fa91@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by bernalex): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 10:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 10:50:45 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.4887c09953026fe5e6da7992cd0d5dfb@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): This was very much an accidental regression, not something consciously done. Makes sense to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 11:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 11:17:46 -0000 Subject: [GHC] #5051: Typechecker behaviour change In-Reply-To: <044.569620fef33303d8ae9785181226236d@haskell.org> References: <044.569620fef33303d8ae9785181226236d@haskell.org> Message-ID: <059.8b33ae6dd9677c5b1f262b25470e2cce@haskell.org> #5051: Typechecker behaviour change -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | typecheck/should_compile/T5051 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): As I say in comment:5, I think this is the right behaviour, so I don't propose to fix it at all. Only leaving it open in case others trip over something similar. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 11:21:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 11:21:47 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.324ad1e335f59165ff16574b8c15004b@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | simplCore/should_compile/T8832 Related Tickets: | Blocking: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high Comment: The bug is fixed. The only issue is that the test has some 64-bit stuff in it, and on a 32-bit machine that doesn't constant-fold. Which is probably fine. To close the ticket we just need to make the test depend on whether we are on a 64-bit machine. I don't know how to do that, but it can't be hard. Could someone do it? I'll make it "high" priority to get it some attention, rather than because it's terribly important. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 12:24:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 12:24:34 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions Message-ID: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} type family F x type instance F Int = Bool foo :: F Int -> () foo True = () bar :: F Int -> () bar 'x' = () }}} I get {{{ /Users/rae/temp/Bug.hs:7:5: Couldn't match type ?Char? with ?Bool? Expected type: F Int Actual type: Bool In the pattern: True In an equation for ?foo?: foo True = () /Users/rae/temp/Bug.hs:10:5: Couldn't match type ?Bool? with ?Char? Expected type: F Int Actual type: Char In the pattern: 'x' In an equation for ?bar?: bar 'x' = () }}} The second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the "Couldn't match ..." bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal. This behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 13:28:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 13:28:30 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.8382c1d03fb11a1852e2f6324db1495b@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------- Reporter: | Owner: ekmett novadenizen | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/random | Operating System: Unknown/Multiple Resolution: | Type of failure: Other Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett (added) * owner: => ekmett Comment: Adding Edward K, since this is really a Core Libraries matter. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 13:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 13:37:24 -0000 Subject: [GHC] #4218: System.Random is way too lazy In-Reply-To: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> References: <048.0b01b9721d2535305bd4a9089fdf6d96@haskell.org> Message-ID: <063.b34e280d364079a4a9e01ce0f7269521@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: ekmett Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: | overflow Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett (added) * owner: rrnewton => ekmett Comment: Making Edward K owner, since it's a Core Libraries issue. Just a question of reviewing the offered patch! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 13:38:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 13:38:04 -0000 Subject: [GHC] #7936: newStdGen leaks memory when result is not used In-Reply-To: <050.05a3639c415d290213c91c5af3af641f@haskell.org> References: <050.05a3639c415d290213c91c5af3af641f@haskell.org> Message-ID: <065.79f3d4f2f0a687def14cabbea2557a8b@haskell.org> #7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------- Reporter: | Owner: ekmett ryantrinkle | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/random | Operating System: Unknown/Multiple Resolution: | Type of failure: Runtime crash Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett (added) * owner: rrnewton => ekmett Comment: Making Edward K owner, since it's a Core Libraries issue Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 13:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 13:47:43 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module In-Reply-To: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> References: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> Message-ID: <064.617f4a1e46261744218b0ad486a18850@haskell.org> #9294: More exports and documentation for GHC API Parser Module -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): That all sounds good to me. Please go ahead and send us a patch. Simon Marlow is best acquainted with the parser and lexer, so it'd be worth checking significant changes with him. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 15:24:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 15:24:06 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.79b52c86b5792686648bff16f12259d1@haskell.org> #8910: cross compiling for x86_64 solaris2 -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Differential Revisions: | Operating System: Solaris Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by maeder): Ok, I've tried again as follows: {{{ git clone git://git.haskell.org/ghc.git cd ghc ./sync-all --no-dph get ## did not work as expected! rm -rf libraries/dph/ echo "INTEGER_LIBRARY = integer-simple" > mk/build.mk perl boot ./configure --target=x86_64-pc-solaris2 --with-ld=/usr/ccs/bin/ld --with- nm=/usr/ccs/bin/nm --with-ar=/usr/ccs/bin/ar --with- ranlib=/usr/ccs/bin/ranlib --prefix=/local/home/maeder/haskell/ghc-7.9-x64 gmake gmake install }}} After setting some additional links: {{{ -bash-3.2$ ls -l /local/home/maeder/haskell/ghc-7.9-x64/bin Gesamt 127 lrwxrwxrwx 1 maeder wimi 35 Jul 15 16:08 ghc -> x86_64-pc- solaris2-ghc-7.9.20140715 lrwxrwxrwx 1 maeder wimi 35 Jul 15 16:09 ghc-7.9.20140715 -> x86_64-pc-solaris2-ghc-7.9.20140715 lrwxrwxrwx 1 maeder wimi 39 Jul 15 16:09 ghc-pkg -> x86_64 -pc-solaris2-ghc-pkg-7.9.20140715 lrwxrwxrwx 1 maeder wimi 39 Jul 15 16:10 ghc-pkg-7.9.20140715 -> x86_64-pc-solaris2-ghc-pkg-7.9.20140715 lrwxrwxrwx 1 maeder wimi 17 Jul 15 16:02 ghci -> ghci-7.9.20140715 -rwxr-xr-x 1 maeder wimi 103 Jul 15 16:02 ghci-7.9.20140715 lrwxrwxrwx 1 maeder wimi 24 Jul 15 16:02 haddock -> haddock- ghc-7.9.20140715 lrwxrwxrwx 1 maeder wimi 25 Jul 15 16:10 hsc2hs -> x86_64-pc- solaris2-hsc2hs lrwxrwxrwx 1 maeder wimi 19 Jul 15 16:02 runghc -> runghc-7.9.20140715 lrwxrwxrwx 1 maeder wimi 6 Jul 15 16:02 runhaskell -> runghc lrwxrwxrwx 1 maeder wimi 35 Jul 15 16:02 x86_64-pc- solaris2-ghc -> x86_64-pc-solaris2-ghc-7.9.20140715 -rwxr-xr-x 1 maeder wimi 428 Jul 15 16:02 x86_64-pc- solaris2-ghc-7.9.20140715 lrwxrwxrwx 1 maeder wimi 39 Jul 15 16:02 x86_64-pc-solaris2 -ghc-pkg -> x86_64-pc-solaris2-ghc-pkg-7.9.20140715 -rwxr-xr-x 1 maeder wimi 460 Jul 15 16:02 x86_64-pc-solaris2 -ghc-pkg-7.9.20140715 -rwxr-xr-x 1 maeder wimi 419 Jul 15 16:02 x86_64-pc-solaris2 -haddock-ghc-7.9.20140715 -rwxr-xr-x 1 maeder wimi 50192 Jul 15 16:04 x86_64-pc- solaris2-hp2ps -rwxr-xr-x 1 maeder wimi 390 Jul 15 16:02 x86_64-pc- solaris2-hpc -rwxr-xr-x 1 maeder wimi 1169 Jul 15 16:02 x86_64-pc- solaris2-hsc2hs -rwxr-xr-x 1 maeder wimi 411 Jul 15 16:02 x86_64-pc- solaris2-runghc-7.9.20140715 }}} The 64Bit compiler was usable (and fully dynamically linked): {{{ -bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/local/home/maeder/haskell/ghc64bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/local/home/maeder/haskell/ghc64bin/gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/usr/ccs/bin/ld") ,("ld flags","") ,("ld supports compact unwind","NO") ,("ld supports build-id","NO") ,("ld supports filelist","NO") ,("ld is GNU ld","NO") ,("ar command","/usr/ccs/bin/ar") ,("ar flags","clqs") ,("ar supports at file","no") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSSolaris2") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.9.20140715") ,("Booter version","7.8.2") ,("Stage","2") ,("Build platform","i386-unknown-solaris2") ,("Host platform","x86_64-unknown-solaris2") ,("Target platform","x86_64-unknown-solaris2") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/local/home/maeder/haskell/ghc-7.9-x64/lib/x86_64-pc- solaris2-ghc-7.9.20140715") ,("Global Package DB","/local/home/maeder/haskell/ghc-7.9-x64/lib/x86_64 -pc-solaris2-ghc-7.9.20140715/package.conf.d") ] }}} With this compiler I tried to bootstrap from scratch: {{{ git clone git://git.haskell.org/ghc.git cd ghc ./sync-all perl boot ./configure --enable-bootstrap-with-devel-snapshot gmake }}} However, this step failed again with a core dump that is already described in comment:2: {{{ "inplace/bin/genprimopcode" --data-decl < compiler/stage1/build/primops.txt > compiler/stage1/build/primop-data-decl .hs-incl /bin/bash: line 1: 17544 Segmentierungsfehler (core dumped) "inplace/bin/genprimopcode" --data-decl < compiler/stage1/build/primops.txt > compiler/stage1/build/primop-data-decl .hs-incl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 15:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 15:29:25 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.b88658a6d19d64d2cb171b6bcd2fe60c@haskell.org> #8910: cross compiling for x86_64 solaris2 -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Differential Revisions: | Operating System: Solaris Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by maeder): P.S. Trying to build just a stage1 (32bit) cross compiler (https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling) by putting "Stage1Only = YES" into mk/build.mk did not work at all. It failed because something tried to use a missing "inplace/bin/ghc-stage2". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 16:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 16:40:05 -0000 Subject: [GHC] #9288: Type class overlapping instances check doesn't understand type equality In-Reply-To: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> References: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> Message-ID: <060.d9672bcaf5e6e22b127a8308f2e5dd8b@haskell.org> #9288: Type class overlapping instances check doesn't understand type equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: invalid | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: This is by design. GHC does not report overlapping instances eagerly (at the instance definition site). Rather it reports them lazily (when used). There is good reason for this: {{{ instance C Int a where instance C b Bool where }}} If we reported errors eagerly we'd have to say they overlap. But there is no problem with, say `(C Int Char)`. It's nothing to do with equalities. The user manual does not say this explicitly, so I'll fix that. Thanks for raising it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 16:40:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 16:40:50 -0000 Subject: [GHC] #9288: Type class overlapping instances check doesn't understand type equality In-Reply-To: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> References: <045.d2fb267eaa92f74ea3b65d76f4535d6b@haskell.org> Message-ID: <060.18dd0ede15669debc477ff32aeb2a605@haskell.org> #9288: Type class overlapping instances check doesn't understand type equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: invalid | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0fcf060418167e05adfbde174b2f030077cb1c1b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0fcf060418167e05adfbde174b2f030077cb1c1b" Improve documentation of overlapping instances (again) Prompted by Trac #9288 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 16:58:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 16:58:44 -0000 Subject: [GHC] #8910: cross compiling for x86_64 solaris2 In-Reply-To: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> References: <045.fc1740e40f861e4b0727d9899c5c10ae@haskell.org> Message-ID: <060.5026c7d82cf7367376ca68f1bf406d55@haskell.org> #8910: cross compiling for x86_64 solaris2 -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Differential Revisions: | Operating System: Solaris Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by maeder): the binary-dist of the cross-compiler (created by "gmake binary-dist") does not contain a configure file. http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-7.9.20140715-x86_64-unknown-solaris2.tar.bz2 (Luckily, "gmake install" produced something usuable.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 16:59:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 16:59:33 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.95ff01243165becb97fd11c6f6084fc4@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: GHC rejects Differential Revisions: | valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 | -------------------------------------+------------------------------------- Comment (by ross): Replying to [comment:42 jstolarek]: > I'm able to compile > > {{{ > test :: Arrow a => a i i > test = proc n -> do > returnA -< n > }}} > > using the new desugaring, which was not possible earlier. I wouldn't have expected any change in the handling of this. > But I'm still stuck on this: > > {{{ > test :: Arrow a => a i i > test = proc n -> do > returnA -< n > returnA -< n > }}} If we're allowing rebinding, that should be type-checked and desugared exactly as if it were written {{{ test :: Arrow a => a i i test = proc n -> (returnA -< n) `thenA` (returnA -< n) }}} Here's the type inference (backwards, the way the checker does it): {{{ D |- proc n -> (returnA -< n) `thenA` (returnA -< n) :: a i t ---------------------------------------------------------------- (ProcExpr) D; n::i |-a (returnA -< n) `thenA` (returnA -< n) : () --> t ------------------------------------------------------------ (ArrForm) D |- thenA :: forall e. a1 (e,s1) i -> a2 (e,s2) i -> a (e,()) t D; n::i |-a1 returnA -< n : s1 --> i ------------------------------------ (ArrApp) D |- returnA :: a1 i i D, n::i |- n :: i D; n::i |-a2 returnA -< n : s2 --> i ------------------------------------ (ArrApp) D |- returnA :: a2 i i D, n::i |- n :: i }}} For the default `thenA`, {{{ thenA :: Arrow a => a (e,s) b -> a (e,s) c -> a (e,s) c u `thenA` v = arr id &&& u >>> arr fst >>> v }}} we have a1 = a2 = a, s1 = s2 = () and t = i, but with rebinding they'd be taken from the type of `thenA`, which could be anything matching the type in the above inference. > I noticed that desugaring of `cmd` stored in the `BodyStmt` always passes `()` as the type of the stack. That's true for the default, but if we have rebinding it will be determined by the type of `thenA`/`bind`. > Ross, I also tried to implement desugaring of `bind`. When generating the desugared Core for `cmd 'bind' \ p -> do { ss }` I have problem with the `\p ->` part. So, given the desugared `do { ss }`, `cmd` and the `bind` operator how should the generated command lambda look like? I'm still at a loss to undestand how to explicitly manipulate the stack from within Core. Here's the type inference: {{{ D; xs |-a cmd1 `bind` \ p -> cmd2 : s --> t ------------------------------------------- (ArrForm) D |- bind :: forall e. a1 (e,s1) t1 -> a2 (e,(b,s2)) t1 -> a (e,s) t D; xs |-a1 :: cmd1 : s1 --> t1 D; xs |-a2 :: \ p -> cmd2 : (b,s2) --> t2 ----------------------------------------- (Lam) D; xs, p::b |-a2 cmd2 : s2 --> t2 }}} In this case the manipulation of the stack is done by the translation of `CmdLam` and by the code inside the vanilla Haskell implementation of `bind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 17:02:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 17:02:15 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.dde084d67920dbae7221fc68bf5821a8@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D70 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by bernalex): * differential: => Phab:D70 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 17:25:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 17:25:35 -0000 Subject: [GHC] #9279: Optimisation bug In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.81438d2ad12a43ecd160b8394269fe6f@haskell.org> #9279: Optimisation bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): You also need to install `aeson`, `unordered-containers`, `stm` and `text` (I think those should be enough). I've collected the log you asked for, it's too big to attach here so I've put it at [http://community.haskell.org/~simonmar/log.bz2]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 18:00:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 18:00:26 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module In-Reply-To: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> References: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> Message-ID: <064.676c0722c553ac45e8f760846d6dcb71@haskell.org> #9294: More exports and documentation for GHC API Parser Module -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by agibiansky): The changes are not at all significant, FYI. It's implemented and I sent a patch (https://phabricator.haskell.org/D71). This covers the first two points, and given the documentation I added, I think the third is not necessary, as it should be fairly straightforward to use the Parser module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 22:25:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 22:25:51 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module In-Reply-To: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> References: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> Message-ID: <064.85396b340b3c7ef1dbfe7f05f48462af@haskell.org> #9294: More exports and documentation for GHC API Parser Module -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D71 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => patch * differential: => Phab:D71 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 22:33:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 22:33:42 -0000 Subject: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD In-Reply-To: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> References: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> Message-ID: <064.57640e46091f6c51dcee168b45751e14@haskell.org> #8013: Strange closure type error building hs-kqueue on FreeBSD -------------------------------------+------------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 (LLVM) | Keywords: Resolution: | Operating System: FreeBSD Differential Revisions: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by ahktenzero): You can close this if you want, I reset the options for GHC and all the Haskell based ports on my system to the defaults a while back and haven't had a reoccurrence of the problem since. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 15 23:28:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jul 2014 23:28:20 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.e8feb8a06add24a143438be4e82bef88@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dimitris@? (added) * owner: => simonpj * priority: normal => high * milestone: => 7.10.1 Comment: Dimitrios, I'd like to discuss this with you when you get back. The behaviour is terrible, and it's a classic case of rewriting a wanted with a wanted. We have {{{ [W] w1 :: F Int ~ Bool -- From foo [W] w2 :: F Int ~ Char -- From bar }}} We try to solve `w2` first: * we rewrite the `F Int` to `Bool`, * add `w2` to the `inert_solved_funeqs` * make `w3` :: Bool ~ Char` (insoluble, correctly) * bind `w2` to evidence involving `w3` and the axiom But now when we try to solve `w1` we find `w2` in the `inert_solved_funeqs` before looking up in the axioms, and thus rewrite to `Char ~ Bool`. Disaster. The problem is putting `w2` (which is really insoluble) in the `inert_solved_funeqs`. Instead I suspect we should put only ''givens'' in the `inert_solved_funeqs`, namely the evidence from the use of the axiom. So solving the second goal would go more like this * we rewrite the `F Int` to `Bool`, with coercion `co` * add `[G] co : F Int ~ Bool` to `inert_solved_funeqs` * create `[W] w3 :: Bool ~ Char` * bind `w2 = co ; w3` Now `inert_solved_funeqs` contains only givens derived directly from axioms, which we can safely use to solve anything. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 00:03:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 00:03:35 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.61ad99d1b37d016ffcfe575a8932aae2@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): This is quite pertinent: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073667.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 00:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 00:30:12 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.6ec9a23ad294601f8873dafa21664ede@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Other Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 01:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 01:04:15 -0000 Subject: [GHC] #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime In-Reply-To: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> References: <045.d6726ef3637dca80ec7040deda3a71db@haskell.org> Message-ID: <060.89ebaafdacc7ec88f4a2d5cef81cb810@haskell.org> #9278: GHCi crash: selector _ for message _ does not match selector known to Objective C runtime -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: crash, dynamic Differential Revisions: | linking Architecture: x86_64 | Operating System: MacOS X (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9277 | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak@? (added) Comment: AFAIK, the Objective-C runtime executes some initialisation code to set up Objective-C classes. The system linker produces executables that ensure that this initialisation is performed before any application code is being run. GHC's runtime doesn't know anything about that, though, and will just load the Objective-C binary code without performing the required runtime initialisation. Based on that, I believe, the error message you are seeing is a consequence of the selectors for the classes not being registered in the data structures used by `objc_msgSend()`. Here is a description of the internals of the ObjC runtime: http://cocoasamurai.blogspot.com.au/2010/01/understanding- objective-c-runtime.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 07:07:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 07:07:04 -0000 Subject: =?utf-8?q?=5BGHC=5D_=239319=3A_nofib-analyze_doesn=E2=80=99t_pro?= =?utf-8?q?vide_per-benchmark_compile_time/alloc_numbers?= Message-ID: <046.71bd0e7229dcd657c9f89ae42cc93a34@haskell.org> #9319: nofib-analyze doesn?t provide per-benchmark compile time/alloc numbers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of general analysis and uniformity, especially with automated monitoring of benchmark numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 07:10:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 07:10:11 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.e4eef1d736ea52f693cb6de0e6db1d26@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: GHC rejects Differential Revisions: | valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:43 ross]: > Replying to [comment:42 jstolarek]: > > I'm able to compile > > > > {{{ > > test :: Arrow a => a i i > > test = proc n -> do > > returnA -< n > > }}} > > > > using the new desugaring, which was not possible earlier. > > I wouldn't have expected any change in the handling of this. Hm... I just realized I probably misunderstood one thing. My desugaring is slightly different, but this is easy to fix. > If we're allowing rebinding, that should be type-checked and desugared exactly as if it were written > > {{{ > test :: Arrow a => a i i > test = proc n -> (returnA -< n) `thenA` (returnA -< n) > }}} I believe that my implementation is doing exactly this. It's just that types don't match. > For the default `thenA`, > {{{ > thenA :: Arrow a => a (e,s) b -> a (e,s) c -> a (e,s) c > u `thenA` v = arr id &&& u >>> arr fst >>> v > }}} > we have a1 = a2 = a, s1 = s2 = () and t = i, but with rebinding they'd be taken from the type of `thenA`, which could be anything matching the type in the above inference. At the moment my implementation does not work even for default `thenA`. I keep looking at the desugaring of monadic do-notation trying to figure out where did I go wrong. I guess the discussion here is more about the details of my implementation. To keep in line with [http://www.haskell.org/pipermail /ghc-devs/2014-July/005562.html recent decisions] I will move it to [https://phabricator.haskell.org/ Phab]. I'll post the link once I've created a new phabricator revision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 07:17:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 07:17:25 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 Message-ID: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- A couple days ago, it was reported to me that vector-algorithms had a significant performance regression (~20x) on GHC 7.8.2. The problem stems from a lack of inlining and specialization of some of the functions that were previously handled in 7.6 and earlier. The following is a reduced test case (the vector and primitive packages are required): {{{ module A (test) where import Control.Monad.ST import Control.Monad import Control.Monad.Primitive import Data.Vector.Generic.Mutable as U test :: (PrimMonad m, MVector v a, Num a) => Int -> v (PrimState m) a -> m a -- test :: (MVector v a, Num a) => Int -> v s a -> ST s a test 0 v = liftM (+1) $ unsafeRead v 0 test n v = do long1 v test (n-1) v {-# INLINABLE test #-} long1, long2, long3, long4 :: (PrimMonad m, MVector v a) => v (PrimState m) a -> m () long1 v = long2 v >> long2 v >> long2 v >> long2 v long2 v = long3 v >> long3 v >> long3 v >> long3 v long3 v = long4 v >> long4 v >> long4 v >> long4 v long4 v = unsafeRead v 0 >>= unsafeWrite v 0 {-# INLINE long1 #-} {-# INLINE long2 #-} {-# INLINE long3 #-} {-# INLINE long4 #-} }}} {{{ module Main (main) where import Control.Monad.ST import Data.Vector.Unboxed.Mutable as U hiding (read) import System.Environment import Unsafe.Coerce import GHC.Prim import A test0 :: Int -> MVector s Int -> ST s Int test0 n v = test n v {-# NOINLINE test0 #-} test1' :: Int -> MVector Any Int -> ST Any Int test1' n v = test n v {-# NOINLINE test1 #-} test1 :: Int -> MVector a Int -> ST a Int test1 = unsafeCoerce test1' main = getArgs >>= \(n:b:_) -> print $ runST $ do v <- new 1 write v 0 0 (if read b then test0 else test1) (read n) v }}} Module `A` exports a single function, `test`. This function is engineered to be quite large, by inlining several other functions into it, and it is itself marked INLINABLE. Then the `Main` module uses this function in two different ways: * `test0` uses `test` at a type that is compatible with `runST` * `test1'` uses `test` at a completely monomorphic type, which is then coerced to a `runST` compatible type in `test1` On 7.6 I believe (though have not checked) that there will be little or no performance difference between `test0` and `test1`. However, on 7.8.2 (and, I have been assured, 7.8.3), there is a massive speed pentalty for `test0`; about 70x on my machine. This seems to be due to no inining or specialization for its use of `test`, which can be seen from `-ddump- simpl`. However, if one changes the type of `test` in `A` to be specific to `ST s` rather than using `PrimMonad`, there is no performance difference, even on 7.8.2. So, the choice to inline and specialize seems to hinge on the instantiation of all the class constraints to monomorphic types containing no variables, rather than just types that resolve all overloading. I myself did not notice this problem, because my benchmark suite uses `IO`, which is a concrete instantiation of the type, and doesn't exhibit this problem. I have temporarily 'fixed' vector-algorithms by moving back to `INLINE` pragmas, but `INLINABLE` is actually preferable in that case, because it generates faster code than `INLINE` when the optimizations actually fire. My test case here does not illustrate that well, though. Is it safe to assume that this was not an intentional change? It's a rather weird rule (to me) if it was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 07:46:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 07:46:16 -0000 Subject: [GHC] #1487: unix package: test needed for getLoginName In-Reply-To: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> References: <047.1ef8c4d73f5dccee00ba133a94dc0060@haskell.org> Message-ID: <062.9828143404a8d02ba67f7c997fee952b@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: closed Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: fixed | Operating System: Linux Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: #8293 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Merged in [https://github.com/haskell/unix/commit/cad1ef27bb0a51bc68ebadb1297de1ae05bee9db unix] package: Enable test for getLoginName Fixes #1487. Make use of no_stdin test option, introduced explictly for this purpose in fa52a8c9d8eae5e3fc4c0cf0e5672875e161e05c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 07:55:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 07:55:15 -0000 Subject: [GHC] #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux In-Reply-To: <047.6577d3b0e4350e5dc6e80e1809edc6cb@haskell.org> References: <047.6577d3b0e4350e5dc6e80e1809edc6cb@haskell.org> Message-ID: <062.8502f4d2c682d6c05069d0279b143c11@haskell.org> #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.1-rc2 libraries/unix | Keywords: Resolution: invalid | Operating System: Linux Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by thomie): Merged: https://github.com/haskell/unix/commit/4c32cd4444270c94249f0f161951c4e9465e7c3e Add haddock comments on RTLD_NEXT and RTLD_DEFAULT Related ticket: #8902. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 08:02:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 08:02:40 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.5de06b49367bb036652f8d3ceea73c0f@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: GHC rejects Differential Revisions: Phab:D72 | valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D72 Comment: I created a phabricator revisionfir this ticket: Phab:D72 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 08:03:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 08:03:50 -0000 Subject: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD In-Reply-To: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> References: <049.81816b82b3a17d10624a4b508e0be873@haskell.org> Message-ID: <064.b1a66b8809a9a99604998ed197c1af7e@haskell.org> #8013: Strange closure type error building hs-kqueue on FreeBSD -------------------------------------+------------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 (LLVM) | Keywords: Resolution: worksforme | Operating System: FreeBSD Differential Revisions: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: infoneeded => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 11:01:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 11:01:28 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.1401365705c671b989343c92c27e4c96@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by scpmw): Haven't followed the discussion so much - so LLVM HEAD can alias arbitrary pointers? That's even more flexibility than we had before. So now we could just close this ticket and take another good look at #4213, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 11:36:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 11:36:23 -0000 Subject: [GHC] #7379: rangeTest test fails on Windows In-Reply-To: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> References: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> Message-ID: <059.ed01df93fcc71d7a1483e6b4fe703a52@haskell.org> #7379: rangeTest test fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/random | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: rrnewton (added) * status: new => patch Comment: https://github.com/haskell/random/pull/5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 12:03:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 12:03:03 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.20b8aaa69fd68bd4078308204f790874@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm looking into this now. I don't really like the optimization in `mkNthCo`. It's almost certainly correct and harmless, but it's quite incompatible with my work on a branch of GHC that has changed coercions quite a bit. (The branch is integrating dependent types into GHC.) And, the problem shouldn't be there in the first place, so that optimization is just masking something deeper. In looking at the minimized test case (thanks!) I'm flummoxed by the dependency on the magical number "10" for the `Options` type. Does that have to do with inliner thresholds? This is an area I'm not familiar with. But, I'm almost positive that the 10-field cutoff is unrelated to the underlying problem of coercion blowup and quartic (!) slowdown. I'm not convinced that the coercion blowup, itself, is so terrible, but quartic behavior certainly is. Will post if I have any more news. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 12:39:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 12:39:07 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.7f55a7847d9a7df382c364301fc4bc4a@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D73 Comment: Have a first attempt up at Phab:D73. More to come. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 15:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 15:24:55 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars Message-ID: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: mvar | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- A lot of code in servers uses MVars because they seem to have more desirable scalability characteristics than STM. Unfortunately, unlike STM which is composable (i.e. `readTChan chan1 <|> readTChan chan2`), `MVar`s often require extra inefficient intermediate steps to funnel many-to-one. A common thing for people to do when they need to funnel N `MVar`s into one is to create 1 `MVar` and N forks where each fork attempts to read from its associated `MVar` and then writes it into the one `MVar` where another fork is waiting to process the data. This is such a waste; it produces more forks and another `MVar` where contention can occur. In some ways it would be better if the internal representation of an `MVar` had a pointer to the "next `MVar`" so that we could use a function like `eitherMVar` to merge two (or more) `MVar`s together into one which can be waited on and yield values from any of the containing `MVar`s. (I believe) the runtime would need to provide appropriate support in the scheduler so that the list is traversed instead of only the single `MVar` checked. The overhead for code which does not use this feature would probably be only 1 branch, which is acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 18:20:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 18:20:57 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.aad42e4d43442100c4bd847ff0e15896@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"34ec0bd942b732b127b1a955cd3508da0a588b6f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="34ec0bd942b732b127b1a955cd3508da0a588b6f" Rewrite coercionRole. (#9233) Summary: coercionRole is now much more efficient, computing both the coercion's kind and role together. The previous version calculated them separately, leading to quite possibly exponential behavior. This is still too slow, but it's a big improvement. Test Plan: Evaluate by running the "minimized" test from the Trac ticket. Reviewers: simonpj, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D73 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 18:20:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 18:20:57 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.5ac16f75c49703ada8f7e37fb5f99dd4@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e7406d9f5857e4ff30aed348f731d16dbd8e64c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5e7406d9f5857e4ff30aed348f731d16dbd8e64c" Optimise optCoercion. (#9233) The old optCoercion (and helper functions) used coercionKind and coercionRole internally. This was terrible when these had to be called at *every* point in the coercion tree during the recursive descent. This is rewritten to avoid such calls. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 18:26:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 18:26:26 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.fcd93c001e6e407d38a249f12e55647a@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Success. The two commits above apply different optimizations to different coercion functions, vastly speeding up the test case. If I increase the size of `X` to include 200 fields, profiling tells me that coercion- oriented functions take about 6% of the ~3 second (MUT) running time. Before these optimizations, the coercion functions were taking up ~98% of the running time, so this is an improvement. :) Before closing the ticket, would someone else like to test the work and confirm that the speedup is enough to close the issue? Lennart, how does this affect your compilation times? I wouldn't be surprised if these commits make a sizable difference: each commit removed potentially- exponential behavior. In any case, I'm stopping work on this for now. Let me know if I need to resume somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 16 18:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jul 2014 18:45:21 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.c0368388ec2d2108c31cd91a85c7f8b0@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html Separately, a change to Core will be necessary to really make this work in all cases. {{{ data X a where MkX :: (F b c ~ a) => b -> c -> X a }}} Say `F` is injective (in both arguments). After pattern-matching on `MkX ... :: X (F Int Bool)`, we will probably want to discover that `b` is `Int` and `c` is `Bool`. To do so, we will need to decompose the `(F b c ~ a)` coercion, using the '''left''' and '''right''' (or perhaps '''nth''') coercion forms. These currently don't work over type families, and for good reason. However, if a type family is injective, then these ''could'' be made to work over type families. With the update to Core, we would probably want to make sure we don't lose type safety, though! All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 03:52:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 03:52:22 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.2766d15655f6d9e3a07b833409d6beb8@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): My understanding of how this would work is as follows. You start with 2 MVars: {{{ m1 <- newMVar m2 <- newMVar }}} You then fuse them, as `MVar`s would [need to be extended to] have an inbuilt linked list of `StgMVar`s they actually represent: {{{ mx <- fuseMVar m1 m2 }}} Readers need to subscribe to every `StgMVar` in their list of `MVar`s ( https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1733 ). They should also write a pointer to the list of `MVar`s they are waiting on to their lightweight thread blocking reason (see below). Writers need to consider that the lightweight thread they are waking may already have been served, or even, processed data so fast they are re- subscribed into the queue in time to save their spot (unlikely, maybe this should be stopped with a gauge). Writers need to test the blocking reason for the lightweight thread (around https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1611 ), and if it's blocking on something, ensure that they are in the supplied list of `StgMVar`s. This is actually only an O(n) operation to do, so it still costs O(1) + 1 branch if the `MVar` hasn't been fused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 04:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 04:01:04 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.dac414724be41ceced2cdd3821084844@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): And finally, the motivation. STM gives us many-to-one waiting. Disadvantages of STM: * Does not scale well because it's not fair Advantage of MVar: * It's fair * It's fast Disadvantages of MVar: * To wait on N channels, have to use N extra forks, 2 MVar puts and N+1 total MVar read operations Advantages of MVar multiple waiting support: * To wait on N channels, have to use no extra forks, 1 MVar put and 1 MVar read operation (with N-1 waiter ignores). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 04:09:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 04:09:04 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.56fe30db203a1819f39adacca4d658dc@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): could the workload you want to handle work with something like https://hackage.haskell.org/package/unagi-chan ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 04:16:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 04:16:27 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.0b41fb6c572c5491a40a1a11f92a78d6@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): likewise, it seems like the async package provides a version of this https://hackage.haskell.org/package/async-2.0.1.5/docs/Control-Concurrent- Async.html#g:6 waitEither :: Async a -> Async b -> IO (Either a b) among others. do you have a specific test case where the mvar or async approaches are too slow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 04:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 04:18:33 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.8e199e8a0977a7d55d1b13afef21a100@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): I think simon marlow has mentioned wanting to explore providing an abstraction thats kinda in between MVar and TMVar, though I don't recall where I've seen him say that, so maybe he can chime in on that (which might be relevant to what you want) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 04:19:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 04:19:20 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.4034ab705aa7c0933973b72fe5dec9f0@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): (The `async` package uses STM, for the benefit of others) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 05:47:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 05:47:34 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.458a0ff2a98214d1e2b98ff8f2c5b085@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Other Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): Are there any -fxxx added for GHC 7.8, which enlarges loaded modules? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 06:44:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 06:44:09 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.4b7ad0c23ce940f163220f4eedd15160@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:40 goldfire]: > I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html So, to be precise, with this syntax the examples from the wiki page would look like this: {{{ type family F a b c | F -> a b c type family G a b c | G -> a b type family H a b c | H a -> b c, H b -> a c, H c -> a b type family J a b c | J a -> b c, J b -> a c }}} I did not propose to use the notation like `H b -> a c` because I thought it might mislead people to think that: a) `H` could be partially applied; b) some parameters of `H` could be skipped (ie. we can apply it to `b` without first applying to `a`). Luckily, this is not a blocking issue for the rest of implementation. It should only affect 3 files in the parser, so it can be changed later. > Separately, a change to Core will be necessary to really make this work in all cases. > > (...) > > All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 07:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 07:15:36 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.a89231a0811308e5667db352fb72b96c@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Some things to think about here: * Could we instead make the STM implementation fairer or faster, if those are the problems? * Before going anywhere, you need to define a complete API (e.g. is `fuseMVar` the only new operation?) and then give the semantics of the new operations. The original Concurrent Haskell paper, or `Tackling the Awkward Squad` gives the style for this semantics. That will force to the surface questions like: * What if you `take` or `put` to a fused `MVar`? * Can the same `MVar` be fused in to several different compounds? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 08:08:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 08:08:14 -0000 Subject: [GHC] #9322: Modify readProcess[WithExitCode] to allow setting current directory Message-ID: <048.5e54c14d88e053ace878139be5424c0e@haskell.org> #9322: Modify readProcess[WithExitCode] to allow setting current directory -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/process | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The readProcess[WithExitCode] function does not allow to modify the working directory parameter passed to createProcess. The documentation states 'readProcess and readProcessWithExitCode are fairly simple wrappers around createProcess. Constructing variants of these functions is quite easy'. I would call that a boldfaced lie, as the implementation of readProcess[WithExitCode] and its web of required, hidden helper functions spans multiple screen pages of subtle and error prone code. Just look at the numerous bug reports for it. It would seem rather unfortunate to extract and copy paste all of this from System.Process just to provide a working directory to a newly created process. Maybe the call should be changed to simply specify a default CreateProcess record so all things like cwd/env could be customized? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 08:48:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 08:48:06 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.138004101973b49831170171280964d5@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"da7cfa99def372cde32af62801a7a7e0163efad8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da7cfa99def372cde32af62801a7a7e0163efad8" Richards optCoercion improvement made test cases fail the nice way This was likely caused by 5e7406d9, which fixed #9233. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 08:57:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 08:57:56 -0000 Subject: [GHC] #9323: Confusing type error behaviour Message-ID: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> #9323: Confusing type error behaviour -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Compile this example with GHC 7.8.3. {{{ module Foo where broken :: [Int] broken = () ambiguous :: a -> String ambiguous _ = show 0 }}} You get {{{ Foo.hs:4:10: Couldn't match expected type ?[Int]? with actual type ?()? In the expression: () In an equation for ?broken?: broken = () Foo.hs:7:15: No instance for (Show a0) arising from a use of ?show? The type variable ?a0? is ambiguous }}} (and a similar ambiguous `(Num a0)` error). '''But if you comment out `broken`, the program compiles.''', using the defaulting rules to choose `a0` = `Integer`. This is obviously wrong. Reported by Evan Laforge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 08:59:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 08:59:40 -0000 Subject: [GHC] #9323: Confusing type error behaviour In-Reply-To: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> References: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> Message-ID: <061.3fe37357e35b3017415ae9b9258ae922@haskell.org> #9323: Confusing type error behaviour -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * version: 7.8.2 => 7.8.3 Old description: > Compile this example with GHC 7.8.3. > {{{ > module Foo where > > broken :: [Int] > broken = () > > ambiguous :: a -> String > ambiguous _ = show 0 > }}} > You get > {{{ > Foo.hs:4:10: > Couldn't match expected type ?[Int]? with actual type ?()? > In the expression: () > In an equation for ?broken?: broken = () > > Foo.hs:7:15: > No instance for (Show a0) arising from a use of ?show? > The type variable ?a0? is ambiguous > }}} > (and a similar ambiguous `(Num a0)` error). > > '''But if you comment out `broken`, the program compiles.''', using the > defaulting rules to choose `a0` = `Integer`. > > This is obviously wrong. > > Reported by Evan Laforge. New description: Compile this example with GHC 7.8.3. {{{ module Foo where broken :: [Int] broken = () ambiguous :: a -> String ambiguous _ = show 0 }}} You get {{{ Foo.hs:4:10: Couldn't match expected type ?[Int]? with actual type ?()? In the expression: () In an equation for ?broken?: broken = () Foo.hs:7:15: No instance for (Show a0) arising from a use of ?show? The type variable ?a0? is ambiguous }}} (and a similar ambiguous `(Num a0)` error). '''But if you comment out `broken`, the program compiles''', using the defaulting rules to choose `a0` = `Integer`. This is obviously wrong. Reported by Evan Laforge. -- Comment: Everything is fine in HEAD. (I don't know which of the many changes between 7.8 and HEAD is responsible.) I'll add a regression test. But I don't propose to fix 7.8. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 09:01:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 09:01:31 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user Message-ID: <044.7996ef569ec65e1751223f37063032df@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: POSIX | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- As a security precaution, GHCi helpfully refuses to run a `.ghci` file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways. This means that .ghci files installed in a global location, say under `/usr/local/`, can then be read. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 09:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 09:01:45 -0000 Subject: [GHC] #9323: Confusing type error behaviour In-Reply-To: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> References: <046.c75a150676320e99ffc6a8acf4082499@haskell.org> Message-ID: <061.b2aa1592ede2027539a79546a51c5007@haskell.org> #9323: Confusing type error behaviour -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ef4e8c54d8dfbceabe53f259ba15f42f6f1b967a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ef4e8c54d8dfbceabe53f259ba15f42f6f1b967a" Test Trac #9323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 09:04:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 09:04:10 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user In-Reply-To: <044.7996ef569ec65e1751223f37063032df@haskell.org> References: <044.7996ef569ec65e1751223f37063032df@haskell.org> Message-ID: <059.320ee9722ca434a70e4be4d5233a6ae1@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: D75 | Operating System: POSIX Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by mboes): * status: new => patch * differential: => D75 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 09:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 09:05:25 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user In-Reply-To: <044.7996ef569ec65e1751223f37063032df@haskell.org> References: <044.7996ef569ec65e1751223f37063032df@haskell.org> Message-ID: <059.9aad9bc99587abbe674d61da3b43ef13@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D75 | Operating System: POSIX Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by mboes): * differential: D75 => Phab:D75 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 11:48:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 11:48:48 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.53da2bdfa8dfedfe35a25dab2f25d1a7@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:41 jstolarek]: > This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. Yes, it's possible, but there are some circumstances in which users could say that GHC gives an erroneous type error, in that GHC would manifestly have enough knowledge to make progress but doesn't. I agree that you should go ahead without this piece, though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 12:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 12:56:46 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.2e446f9c9bf0b51b15c1ee03d6604326@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: diatchki, martin.sulzmann@? (added) Comment: Martin, Iavor, I'd welcome feedback about the proposed course of action in comment:14 above. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 13:19:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 13:19:50 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.89ed954c4fcc33036cf8a7262cdbe6cd@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Some questions for Richard: * In the first commit "Rewrite coercionRole", there is a small change in `OptCoercion`, whicg does entirely un-commented. What's it about? Could you comment it? A Note? * In the new `OptCoercion` (after both commits) I see that `opt_co1` is called only with `Nothing` as its third arg. So can we get rid of that arg? * Ditto `opt_co2`. (In contrast `opt_co3` does have non-Nothing calls. It's the only one that does. * Do those changes change something in `Note [Optimising coercion optimisation]`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 14:03:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 14:03:11 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.f29e1e3c6ceed600788b48450a0921a3@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:20 simonpj]: > Some questions for Richard: > > * In the first commit "Rewrite coercionRole", there is a small change in `OptCoercion`, whicg does entirely un-commented. What's it about? Could you comment it? A Note? Those changes are just to take advantage of the new efficiency available by calling `coercionKindRole` instead of `coercionKind` and `coercionRole` separately. I don't think further explanation is needed -- there's no change in behavior or algorithm really. > > * In the new `OptCoercion` (after both commits) I see that `opt_co1` is called only with `Nothing` as its third arg. So can we get rid of that arg? Yes. I was unsure when originally structuring the new `opt_co` variants if we'd need those parameters, and forgot to go back and double-check. I wil do this. > > * Ditto `opt_co2`. (In contrast `opt_co3` does have non-Nothing calls. It's the only one that does. Ditto here. > > * Do those changes change something in `Note [Optimising coercion optimisation]`? No. > > Great work BTW. > > Simon Thanks for checking things over! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 14:07:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 14:07:26 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.7a900096d87f12bcb2b378e5de89a05d@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"612d948b159c209020c12479a846af5b42e9601e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="612d948b159c209020c12479a846af5b42e9601e" Remove unused parameters in OptCoercion (#9233) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 14:35:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 14:35:49 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.7054931bedc0df718c1a49531ba5ca00@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Re first bullet, yes I see now. Silly me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 18:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 18:10:22 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.1656df265eeb1e7822564f51d5939ea6@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Other Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): GHC loads more interface files in 7.8.x, due to the AMP warnings. This does make it use more memory (but a constant amount per compilation). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 19:20:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 19:20:44 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered Message-ID: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: mod73 | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Difficulty: Unknown Test Case: mod73 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The correct output from the mod73 test needs to be reordered in HEAD: {{{ =====> mod73(normal) 1610 of 4044 [0, 0, 0] cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./module/mod73.stderr 2014-07-16 21:21:57.000000000 +0100 +++ ./module/mod73.comp.stderr 2014-07-17 20:15:54.000000000 +0100 @@ -2,6 +2,6 @@ mod73.hs:3:7: Not in scope: ?Prelude.g? Perhaps you meant one of these: - data constructor ?Prelude.LT? (imported from Prelude), + data constructor ?Prelude.GT? (imported from Prelude), data constructor ?Prelude.EQ? (imported from Prelude), - data constructor ?Prelude.GT? (imported from Prelude) + data constructor ?Prelude.LT? (imported from Prelude) *** unexpected failure for mod73(normal) Unexpected results from: TEST="mod73" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 17 23:38:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jul 2014 23:38:35 -0000 Subject: [GHC] #9326: Minor change to list comprehension structure leads to poor performance Message-ID: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> #9326: Minor change to list comprehension structure leads to poor performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- According to [http://stackoverflow.com/questions/24690406/haskell-list- comprehension-speed-inconsistencies] ''and my own testing'', the code in compspeed.hs reliably runs several times faster than the code in compspeedslow.hs with ghc 7.8.3, although this apparently does not happen with 7.6.3. The basic distinction is between a list comprehension of the form {{{ [(a,h) | ..., let h = expr] }}} and {{{ [(a,expr) | ...] }}} The core produced by -ddump-simpl is completely different in each case, so I can't figure out what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 00:06:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 00:06:53 -0000 Subject: [GHC] #9327: possibly incorrect indentation or mismatched brackets Message-ID: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> #9327: possibly incorrect indentation or mismatched brackets -------------------------------------+------------------------------------- Reporter: Jefffrey | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Differential Revisions: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- I'm having a weird problem. This code compiles: {{{ fetchSomething :: IO String fetchSomething = return "Something" main :: IO () main = do if True then do l <- fetchSomething let fn s = do let rs = s ++ ": " l <- fetchSomething return $ rs ++ l n <- fn "Prefix" putStr n else return () }}} but the following doesn't: {{{ let ep = Bridge.destination b e ed <- doesDirectoryExist ep if ed then do ds <- listDirs ep let fn p = do let t = readUTC p lt <- toLocalTime t <-- parse error (possibly incorrect indentation or mismatched brackets) return $ Snapshot t lt e b l <- mapM fn ds let r = sortBy (compare `on` time) l let ri = Prelude.take m $ assignIDs 1 r if o == Oldest then return $ ri else return $ reverse ri else return [] }}} Here's a live demo of the former: http://coliru.stacked- crooked.com/a/0305f546c8566683 To test the second, the only way I could find is by downloading this repository: https://github.com/Jefffrey/Kopia/commit/9ec9eb93183c4ceed6d324f7fc726584de02755c and running `cabal test`. Someone on the #haskell channel reproduced it on his machine too. This seems like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 00:12:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 00:12:01 -0000 Subject: [GHC] #9327: possibly incorrect indentation or mismatched brackets In-Reply-To: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> References: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> Message-ID: <062.5220e6a497898dcbd07f67efe032d0ed@haskell.org> #9327: possibly incorrect indentation or mismatched brackets -------------------------------------+------------------------------------- Reporter: Jefffrey | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Differential Revisions: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Jefffrey): The person that tested it on his machine states he is running it on GHC 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 00:15:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 00:15:37 -0000 Subject: [GHC] #9326: Minor change to list comprehension structure leads to poor performance In-Reply-To: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> References: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> Message-ID: <060.b4453c90a72ed2c745784f6320302917@haskell.org> #9326: Minor change to list comprehension structure leads to poor performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > According to [http://stackoverflow.com/questions/24690406/haskell-list- > comprehension-speed-inconsistencies] ''and my own testing'', the code in > compspeed.hs reliably runs several times faster than the code in > compspeedslow.hs with ghc 7.8.3, although this apparently does not happen > with 7.6.3. The basic distinction is between a list comprehension of the > form > > {{{ > [(a,h) | ..., let h = expr] > }}} > > and > > {{{ > [(a,expr) | ...] > }}} > > The core produced by -ddump-simpl is completely different in each case, > so I can't figure out what's going on. New description: According to [http://stackoverflow.com/questions/24690406/haskell-list- comprehension-speed-inconsistencies] ''and my own testing'', the code in compspeed.hs reliably runs several times faster than the code in compspeedslow.hs with ghc 7.8.3. It seems 7.8.3 is compiling the "fast" code better than 7.6.3 did, but compiling the "slow" code about the same. The basic distinction is between a list comprehension of the form {{{ [(a,h) | ..., let h = expr] }}} and {{{ [(a,expr) | ...] }}} The core produced by -ddump-simpl is completely different in each case, so I can't figure out what's going on. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 06:37:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 06:37:42 -0000 Subject: [GHC] #9326: Minor change to list comprehension structure leads to poor performance In-Reply-To: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> References: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> Message-ID: <060.ad865b446d23bf7fdc78b7c34ca14276@haskell.org> #9326: Minor change to list comprehension structure leads to poor performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 08:26:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 08:26:38 -0000 Subject: [GHC] #9328: MINIMAL pragma should supprt negation Message-ID: <047.2b12e5ee74ebfc9850e94c944d8e3a10@haskell.org> #9328: MINIMAL pragma should supprt negation -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Consider this class declaration {{{ class Conv a where to :: Integer -> a from :: a -> Integer default to :: (Generic a) => Integer -> a to i = ... default from :: (Generic a) => a -> Integer from a = ... }}} The class provides default methods for the two methods using generics. An instance declaration for this type is likely to want to use the default for both methods or for none. So I'd like a MINIMAL pragma that can express this. E.g. {{{ {-# MINIMAL (to, from) | (!to, !from) #-} }}} I've used ! for negation (following the lead set by the MINIMAL pragma using a non-Haskell OR operator), so this says: either implement 'to' and 'from' or don't implement neither 'to' nor 'from'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 08:31:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 08:31:21 -0000 Subject: [GHC] #9328: MINIMAL pragma should supprt negation In-Reply-To: <047.2b12e5ee74ebfc9850e94c944d8e3a10@haskell.org> References: <047.2b12e5ee74ebfc9850e94c944d8e3a10@haskell.org> Message-ID: <062.003af64c32ff5c1b5ec7521f4f0a3dcb@haskell.org> #9328: MINIMAL pragma should supprt negation -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): That?s no longer a statement of what instances are `MINIMAL`, but rather a complete description of sensible instantiations, isn?t it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 08:36:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 08:36:47 -0000 Subject: [GHC] #9326: Minor change to list comprehension structure leads to poor performance In-Reply-To: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> References: <045.1c317aaff8c19da25888a5984a88d8bc@haskell.org> Message-ID: <060.decd49c1f405c63e7bcf6c35d6704232@haskell.org> #9326: Minor change to list comprehension structure leads to poor performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: In 'comdspeed' one more rule did fire (to specialze .find on Ints): {{{ "SPEC find [(Int, Int)]" [ALWAYS] forall @ a3_a2Tz $dOrd_s2U0. find $dOrd_s2U0 = $sfind }}}. It's seen in core comparison when use '''-ddump-simp -dsuppress-all'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 09:25:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 09:25:52 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.6e23660b356125964b0af16149ec5a39@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D73 | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): Is there a test case we can add to the perf tests? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 09:26:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 09:26:43 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.14912ae4cf363b0dc902520a22ec46c5@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): I think it's really really hard to add support for multi-MVar operations. So I'm with Simon: we should put our efforts into improving STM instead. On the fairness point, MVar's fairness guarantee means that MVar actually performs quite badly under contention, due to the excessive number of context switches. Have you measured your application using both MVar and STM? STM transactions with only a few TVars perform quite well in my experience, and tend to outperform MVar under heavy contention. Nevertheless, if you want to go ahead with this, you'll need (a) a clear description of the desired semantics, and (b) a detailed implementation plan. I think you'll encounter lots of problems trying to do both of these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 12:54:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 12:54:47 -0000 Subject: [GHC] #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` Message-ID: <042.61b5d8d63186bd136b03c5418b6145b5@haskell.org> #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The following Cmm code snippet compiles fine {{{#!c foo () { STK_CHK_GEN_N (((1)*8)); /* works */ return (0); } }}} The following one, however, only compiles with `-O0`, but panics with `-O1` or more: {{{#!c foo () { STK_CHK_GEN_N (8); /* panics */ return (0); } }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): bundle c1 foo [(c1, label: block{v c1}_info rep:StackRep [])] [(c0, {}), (c3, {})] foo() // [] { info_tbl: [(c1, label: block{v c1}_info rep:StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c0: R1 = 0; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 13:24:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 13:24:00 -0000 Subject: [GHC] #9327: possibly incorrect indentation or mismatched brackets In-Reply-To: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> References: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> Message-ID: <062.d26f1f6f1efb7839c4288af8151904ae@haskell.org> #9327: possibly incorrect indentation or mismatched brackets -------------------------------------+------------------------------------- Reporter: Jefffrey | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Differential Revisions: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: You are doing something very weird here, mixing two different levels of indentation. I think you probably want {{{ let ep = Bridge.destination b e ed <- doesDirectoryExist ep if ed then do ds <- listDirs ep let fn p = do -- The following three lines are part of the 'do' -- They are not new binding in the 'let', peer to 'fn' let t = readUTC p lt <- toLocalTime t return $ Snapshot t lt e b l <- mapM fn ds let r = sortBy (compare `on` time) l let ri = Prelude.take m $ assignIDs 1 r if o == Oldest then return $ ri else return $ reverse ri else return [] }}} If in doubt, use braces and semi-colons: {{{ let ep = Bridge.destination b e ed <- doesDirectoryExist ep if ed then do { ds <- listDirs ep ; let fn p = do -- The following three lines are part of the 'do' -- They are not new binding in the 'let', peer to 'fn' { let t = readUTC p ; lt <- toLocalTime t ; return $ Snapshot t lt e b } ; l <- mapM fn ds ; let r = sortBy (compare `on` time) l ; let ri = Prelude.take m $ assignIDs 1 r ; if o == Oldest then return $ ri else return $ reverse ri } else return [] }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 14:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 14:34:01 -0000 Subject: [GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints In-Reply-To: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> References: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> Message-ID: <062.3f5737e5df441593b82cb165a29f1034@haskell.org> #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4b3df0bb705c9287046c07bbc6c038960fbf8d53/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b3df0bb705c9287046c07bbc6c038960fbf8d53" Further improvements to floating equalities This equality-floating stuff is horribly delicate! Trac #9316 showed up yet another corner case. The main changes are * include CTyVarEqs when "growing" the skolem set * do not include the kind argument to (~) when growing the skolem set I added a lot more comments as well }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 14:36:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 14:36:08 -0000 Subject: [GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints In-Reply-To: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> References: <047.3e08ece466a818f844fb33b47be1c8dd@haskell.org> Message-ID: <062.a4830dd6373b420a29321dfb18e2c45e@haskell.org> #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * milestone: => 7.8.4 Comment: I'm not honestly sure exactly what changed between 7.8.2 and 7.8.3, but the fixed code is much more robust. Thank you for this test case. I hope you can work around it for now. If we ever release 7.8.4 this should go in, so I'll make it patch status on that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 15:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 15:18:33 -0000 Subject: [GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". Message-ID: <046.9f9b875883fbae34683c004793d8a328@haskell.org> #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- A common use case for `on` (from `Data.Function`) is to use it with `compare`, e.g. {{{compare `on` snd}}}. In fact, this pattern is so common that there's a convenient `comparing` function which provides a shortcut for this use case such that one can write {{{ #!haskell sortBy (comparing snd) }}} instead of {{{ #!haskell sortBy (compare `on` snd) }}} I think another common use case is to use `on` together with `(==)` as in {{{ #!haskell groupBy ((==) `on` snd) }}} In a similiar vein as with `comparing`, I think it would be nice if there was a function which encapsulates this use case, like {{{ #!haskell equating :: Eq b => (a -> b) -> a -> a -> Bool equating = on (==) }}} such that one can write {{{ #!haskell groupBy (equating snd) }}} The (IMHO fairly nice) name `equating` is not my idea but was suggested by //ClaudiusMaximus// of #haskell fame. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 15:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 15:25:13 -0000 Subject: [GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". In-Reply-To: <046.9f9b875883fbae34683c004793d8a328@haskell.org> References: <046.9f9b875883fbae34683c004793d8a328@haskell.org> Message-ID: <061.7e51fdd4b9ccaf20fd8b7a25f3473dca@haskell.org> #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by frerich): A lot of `*By` functions taking an `a -> a -> Bool` are in `Data.List`, e.g. `groupBy`, `nubBy`, `deleteBy`, `intersectBy`, `unionBy`. Hence, it seems plausible to define `equating` in `Data.List`. This is the same reasoning as why `comparing` is in `Data.Ord`: because the module exposes a lot of `*By` functions taking an `a -> a -> Ordering`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 15:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 15:43:56 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs (was: CPP warnings on ghcautoconf.h) In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.064b53fd657722b39fd86a939fa92ba7@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by asr): * version: 7.8.2 => 7.8.3 Old description: > The cpphs program yields the following warning: > > {{{ > Warning: trailing characters after #if directive in file ... > /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD > }}} > > I guess it is necessary to replace `#if defined` by `#ifdef` in the line > {{{ > #if defined AC_APPLE_UNIVERSAL_BUILD > }}} > from the mk/config.h.in file. > > Note the next line `# if defined __BIG_ENDIAN__` has the same issue. New description: cpphs 1.18.5 yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line {{{ # if defined __BIG_ENDIAN__ }}} has the same issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 15:45:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 15:45:06 -0000 Subject: [GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". In-Reply-To: <046.9f9b875883fbae34683c004793d8a328@haskell.org> References: <046.9f9b875883fbae34683c004793d8a328@haskell.org> Message-ID: <061.feef5544d40a623198dadd6194b104d4@haskell.org> #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): A couple of items: Historically, `comparing` was actually defined before `on` was added to `base`. Fear that we'd be duplicating that pattern over and over again for every other function under the sun led to the adoption of `on`. `equating` was explicitly the original motivation! `comparing` was left in because it was already there, but not _really_ intended to be a pattern to copy, `on` was the general solution put forth to avoid precisely this repetition. The main reason why we should consider doing this is, well, frankly, it gets reinvented every 6 months, so by not doing it we seem to be on the wrong side of history. Eventually someone will say yes. ;) That said, library changes like this should go through a libraries at haskell.org request, rather than trac. Please submit this as a libraries@ mailing list proposal, that'll garner general sentiment and the core libraries committee can weigh in there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 15:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 15:45:47 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.6d6e586043ea7aee2cbb553e848a2d40@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp -------------------------------------+------------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (NCG) | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by slyfox): Managed to squeeze M-mini into even shorter example: {{{ -- a.hs module M (f) where f :: Int -> Int f i = go [ 1, 0 ] where go :: [Int] -> Int go [] = undefined go [1] = undefined go (x:xs) | x == i = 2 | otherwise = go xs }}} profiled -HEAD can even show stack trace: {{{ [sf] /tmp:~/dev/git/ghc/inplace/bin/ghc-stage2 --make -O2 a.hs [1 of 1] Compiling M ( a.hs, a.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140712 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_sNc Stack trace: AsmCodeGen.RegAlloc (compiler/nativeGen/AsmCodeGen.lhs:(521,27)-(523,55)) AsmCodeGen.cmmNativeGen (compiler/nativeGen/AsmCodeGen.lhs:379:47-95) CodeOutput.NativeCodeGen (compiler/main/CodeOutput.lhs:153:18-69) CodeOutput.OutputAsm (compiler/main/CodeOutput.lhs:(151,37)-(153,69)) HscMain.codeOutput (compiler/main/HscMain.hs:(1180,16)-(1181,50)) GhcMake.upsweep_mod.compile_it (compiler/main/GhcMake.hs:(1186,13)-(1188,66)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1135,1)-(1280,49)) GhcMake.upsweep.upsweep' (compiler/main/GhcMake.hs:(1068,3)-(1124,64)) GhcMake.upsweep (compiler/main/GhcMake.hs:(1063,1)-(1124,64)) GhcMake.load (compiler/main/GhcMake.hs:(150,1)-(369,38)) GHC.defaultCleanupHandler (compiler/main/GHC.hs:(384,1)-(390,11)) GHC.runGhc (compiler/main/GHC.hs:(414,1)-(419,7)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 17:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 17:08:46 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.6391610efcbe1bfcd05f1124ab384f87@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries -------------------------------------+------------------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build | Version: 7.5 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by boo): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: I'm just trying to crosscompile GHC-7.8.3 from Linux (x86) to Raspberry Pi following [wiki:Building/Preparation/RaspberryPi this instruction] and getting following error: {{{ "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install "" --with-ghc="/home/boo/projects/rpi/ghc-7.8.3/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/boo/projects/rpi/ghc-7.8.3/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --enable-library- vanilla --disable-library-profiling --enable-shared --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --configure-option=--host=arm-unknown-linux-gnueabihf --with- gcc="/usr/bin/gcc" --with-ld="/home/boo/projects/rpi/tools/arm-bcm2708 /gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-ld" --configure-option=--with-cc="/usr/bin/gcc" --with- ar="/home/boo/projects/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-ar" --with- ranlib="/home/boo/projects/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-ranlib" --with- alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy" Configuring ghc-prim-0.3.1.0... ghc-cabal: /tmp/3624.o: does not exist make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 17:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 17:23:28 -0000 Subject: [GHC] #9331: Release Cabal 1.22 before GHC 7.10 release Message-ID: <045.bbcbad638a01bcc0aa536c05de8920b5@haskell.org> #9331: Release Cabal 1.22 before GHC 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Package system | Version: 7.9 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Just a tracking bug so we don't forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 20:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 20:32:25 -0000 Subject: [GHC] #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". In-Reply-To: <046.9f9b875883fbae34683c004793d8a328@haskell.org> References: <046.9f9b875883fbae34683c004793d8a328@haskell.org> Message-ID: <061.9259a4bcd75104ddcd53b05dd606c4e8@haskell.org> #9330: Introduce shortcut for "on (==)" much like there's a shortcut for "on compare". -------------------------------------+------------------------------------- Reporter: frerich | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by hvr): Fairbairn-threshold, anyone? :) {{{#!hs > length "equating" > length "on (==)" True }}} (fwiw, I would rather see `on` being exported by `Prelude` than add `equating` to `Data.Eq`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 18 23:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jul 2014 23:11:13 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 In-Reply-To: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> References: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> Message-ID: <059.b0ad1973309ba70f092f7d96cf95bbd2@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you certain that this ever worked, in any version of GHC? What's happening is that we see {{{ test0 = /\s. \n v. test @ Data.Vector.Unboxed.Base.MVector @ (GHC.ST.ST s) @ GHC.Types.Int ($dPrimMonad_s1Mw @ s) ... }}} We run over the program gathering up specialised cals to `test`, but this one is discarded again because the `/\s` means that the `s` type variable in the call isn't visible at top level. To fix this we need to make the specialiser a bit cleverer, so that it'll generate a RULE like {{{ RULE forall s (d:forall s. PrimMonad (ST s)). test @ MVector @ (ST s) @ Int (d @ s) = $stest s }}} with accompanying definition {{{ $stest = /\s. @ MVector @ (ST s) @ Int ($dPrimMonad_s1Mw @ s) }}} GHC has never done this. It could do, but it's a new thing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 01:59:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 01:59:26 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.65249bdafaef6f82bc5f1db8d3a02d2e@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): I have been hacking together a benchmark for STM (attached) first, then later I will put together the equivalent thing for MVar. On my i7 haswell macbook pro I compile and run it like this: {{{ $ ghc -O2 -threaded -fforce-recomp Bench.hs $ time ./Bench +RTS -N8 }}} This emulates the exact use case I mentioned for the server above, actually. We have * A packets queue, bounded, written and read by only 1 * An events chan, unbounded and written by everything (but individual forks) * A commands queue, bounded, written and read by 5% of the clients (but individual forks) In terms of the configurable parameters: * `threshold` is how many events, commands OR packets clients want before they just disconnect. I needed a fair simulation of throughput * `clients` is the number of clients to simulate connected to the server * There are adjustable delays on the client-local chans you can adjust, `packetDelay`, `eventDelay` and `commandDelay`. This is just to give a kind of estimate of the actual distribution of messages in a real server (I expect i.e. there to be 50 events per 1 actual client packet per 5 client-specific commands) Interestingly the bench terminates in 4 seconds when `clients = 20`. I set `clients = 40` and couldn't get it to terminate for over 5 minutes (and my laptop was really hot) so I killed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 02:00:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 02:00:32 -0000 Subject: [GHC] #5645: Sharing across functions causing space leak In-Reply-To: <044.215b2b04450d31ff471da80f52f87921@haskell.org> References: <044.215b2b04450d31ff471da80f52f87921@haskell.org> Message-ID: <059.0fa0c59d25087b1ee6b454fc59329209@haskell.org> #5645: Sharing across functions causing space leak -------------------------------------+------------------------------------- Reporter: tener | Owner: Type: bug | Alexander.Pakhomov Priority: normal | Status: new Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.2.1 Differential Revisions: | Keywords: Architecture: | Operating System: Unknown/Multiple Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Changes (by Alexander.Pakhomov): * owner: => Alexander.Pakhomov * difficulty: => Unknown Comment: I hope this could be done with GC modifications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 02:08:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 02:08:12 -0000 Subject: [GHC] #9321: Support for waiting on multiple MVars In-Reply-To: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> References: <046.b6b8f8b65ab25c961750ca3df0135509@haskell.org> Message-ID: <061.6a288bd84298fff517a690aa32e9c216@haskell.org> #9321: Support for waiting on multiple MVars -------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: mvar System | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): I will see if benching MVar over the same thing is any better, and then talk about proposed API, semantics etc soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 02:16:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 02:16:20 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 In-Reply-To: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> References: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> Message-ID: <059.0e60162b35023bb46c32827a10ce9932@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dolio): Apparently I am not certain. I've conferred with some people, and my example displays the same behavior on 7.6.3. The intention was to simulate the behavior of the following test: {{{ module Main (main) where import qualified Data.Vector.Algorithms.Intro as I import qualified Data.Vector.Unboxed as U main = do let a = U.fromList [0..10000000::Int] print (U.length a) let k = U.modify (\v -> I.sort v) a print (U.length k) }}} which is an order of magnitude slower on 7.8 than on 7.6 (note, if you choose to test this, you must use vector-algorithms 0.6.0.1; I have semi- fixed the issue in 0.6.0.2). Running with -ddump-simpl yields 640 lines on 7.8.{2,3}, and ~4,600 lines on 7.6.3. So clearly the difference involves some variety of inlining or specialization. The type of {{{sort}}} here is: {{{(PrimMonad m, MVector v e, Ord e) => v (PrimState m) e -> m ()}}} and the type of {{{modify}}} is: {{{Unbox a => (forall s. MVector s a -> ST s ()) -> Vector a -> Vector a}}} So my aim was to replicate the kind of specialization as the sorting example. But clearly I've failed. However, if your description is correct, I have no idea why 7.6.3 was inlining/specializing the sort function in this example. It has the same open s, necessarily, due to the higher rank type of {{{modify}}}. Can you think of anything that might be the difference? ---- In another direction, it might be interesting to do the kind of specialization you outline above. The {{{PrimMonad}}} dictionary is completely determined even though the function is polymorphic in {{{s}}}, and specializing the function is key to performance, even if some parts are still polymorphic (as they necessarily are for {{{ST}}}). Failing to unbox all the {{{Int}}} operations and so on merely because we are still abstracting over {{{s}}} makes {{{PrimMonad}}} a rather unusable abstraction. I actually tried (earlier) adding a pragma: {{{ {-# SPECIALIZE sort :: MVector s Int -> ST s () #-} }}} but GHC complained about it. So it seems that it can't even handle what that sort of thing generates, ignoring the fact that it can't generate it itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 02:53:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 02:53:23 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 In-Reply-To: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> References: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> Message-ID: <059.3c0eac4c7efcd64c549de2183ea3e98d@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): I believe that SPECIALIZE works better in 7.9 onwards ( or at least, the fix for my own specialize pragmas failing was sorted out there) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 05:15:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 05:15:03 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.2daa984a6f209ee427040271949c27f2@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 6.8.1 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by pumpkin): Dan Doel pointed out that as useful as this could be, it would allow this fairly odd use case: {{{ #!haskell data Nat = Z | S Nat data Fin n where Zero :: Fin (S n) Suc :: Fin n -> Fin (S n) newtype SomeFin where SomeFin :: Fin n -> SomeFin suc :: SomeFin -> SomeFin suc (SomeFin n) = SomeFin (Suc n) inf :: SomeFin inf = suc inf }}} Which leads to `inf` containing a `Fin` whose existential index can't actually be any valid (finite) type. `Fin` thus becomes a bit of a misnomer in this context, since it's not finite. Making `SomeFin` into data rather than newtype fixes the problem by making `inf` into a bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 07:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 07:00:03 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.d6cbac527fe32d40ded3fd7e6e39fc47@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): The perf tests don't guarantee to pass unless you use the validate settings, I think that's unavoidable. Maybe it's possible to just skip them unless the correct settings are being used. We don't use -O2 in validate because validate is supposed to be fast. But that doesn't render the perf tests useless, they're just testing -O and not -O2 (and individual tests can use -O2 if we want). Should we force -O2 for Data.Typeable.Internal? A tricky one. I generally don't like forcing optimisation settings for individual modules like this, because it prevents us from seeing the real effect of global optimisation settings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 08:00:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 08:00:33 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.16abb9072cdae796e19217d3ba4edd13@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > The perf tests don't guarantee to pass unless you use the validate settings, I think that's unavoidable. True; but it seems that we would want to validate the settings used for release, aren?t we? Otherwise there might be a regression affecting our releases, and we won?t notice.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 08:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 08:18:10 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.22fbf0052986d364dd2531d724a4421a@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:11 nomeata]: > > The perf tests don't guarantee to pass unless you use the validate settings, I think that's unavoidable. > > True; but it seems that we would want to validate the settings used for release, aren?t we? Otherwise there might be a regression affecting our releases, and we won?t notice.... There are *lots* of things that validate doesn't test for, and lots of regressions that it won't catch. It's a compromise between coverage and speed, deliberately. For instance, it doesn't test profiling at all - yet that's an important feature of our releases. We need to make the full testsuite runs more visible to developers, and focus on fixing regressions that they find. I suspect that adding -O2 to libraries and compiler (we would have to do both) would make validate slower, but I don't know how much; feel free to measure it. I do think validate is too slow already, though, and we should be finding ways to speed it up. The full testsuite run should use -O2 (I think I used to do that when I did the nightly builds), and the perf tests should have a separate set of figures for when libraries are built with -O2 where necessary. Probably only this one test will need to have different results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 10:58:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 10:58:16 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci Message-ID: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: ghci, strict, | Differential Revisions: memory | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- (http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict- sum-strict-foldl-in-ghci) Suppose we have {{{ --Test.hs import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList main = do print $ result }}} If one deletes all the ".hi" and ".o" files and then loads into ghci via : {{{ ghci -fobject-code Test.hs }}} then upon running "main" the memory blows up. However if one first compiles via : {{{ ghc Test.hs }}} and then subsequently loads into ghci via : {{{ ghci Test.hs }}} then upon running "main" the memory does not blow up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 11:49:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 11:49:30 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.7dc0afd7974497a33c5122e1fcd83479@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by jrp): Running with the validate settings (ie, running validate) I get all the performance tests to pass other than: {{{ =====> T4801(normal) 1987 of 4045 [0, 0, 0] cd ./perf/compiler && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs +RTS -V0 -tT4801.comp.stats --machine- readable -RTS -static >T4801.comp.stderr 2>&1 max_bytes_used value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T4801(normal) max_bytes_used: 25145320 +/-5% Lower bound T4801(normal) max_bytes_used: 23888054 Upper bound T4801(normal) max_bytes_used: 26402586 Actual T4801(normal) max_bytes_used: 23720120 Deviation T4801(normal) max_bytes_used: -5.7 % peak_megabytes_allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T4801(normal) peak_megabytes_allocated: 70 +/-1% Lower bound T4801(normal) peak_megabytes_allocated: 69 Upper bound T4801(normal) peak_megabytes_allocated: 71 Actual T4801(normal) peak_megabytes_allocated: 68 Deviation T4801(normal) peak_megabytes_allocated: -2.9 % bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T4801(normal) bytes allocated: 464872776 +/-5% Lower bound T4801(normal) bytes allocated: 441629137 Upper bound T4801(normal) bytes allocated: 488116415 Actual T4801(normal) bytes allocated: 415645496 Deviation T4801(normal) bytes allocated: -10.6 % *** unexpected failure for T4801(normal) }}} This is on OS X with the master HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 12:54:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 12:54:20 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.17319845ad7c43ed1abf6bac14216fa7@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Description changed by artella.coding: Old description: > (http://stackoverflow.com/questions/24838982/memory-blowing-up-for- > strict-sum-strict-foldl-in-ghci) > > Suppose we have > > {{{ > --Test.hs > import Data.List > > longList::[Int] > longList = [1 .. ] > > result :: Int > result = foldl' (+) 0 $ takeWhile (< 10000000) longList > > main = do > print $ result > }}} > > If one deletes all the ".hi" and ".o" files and then loads into ghci via > : > > {{{ > ghci -fobject-code Test.hs > }}} > > then upon running "main" the memory blows up. > > However if one first compiles via : > > {{{ > ghc Test.hs > }}} > > and then subsequently loads into ghci via : > > {{{ > ghci Test.hs > }}} > > then upon running "main" the memory does not blow up. New description: (http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict- sum-strict-foldl-in-ghci) Suppose we have {{{ --Test.hs import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList main = do print $ result }}} If one deletes all the ".hi" and ".o" files and then loads into ghci via : {{{ ghci -fobject-code Test.hs }}} then upon running "main" the memory blows up. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 12:55:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 12:55:25 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.f30ae07d1f55196b2f1da124de471b1d@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by artella.coding): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 13:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 13:18:56 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.d86324773373b60f5ab78a073d0554a1@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by artella.coding): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 13:33:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 13:33:34 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.d32bb6579857e8f357bbf52b5dce226a@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by artella.coding): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 14:47:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 14:47:50 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.0dac21ce1c1a55e47edf6b557bab01f4@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I?m very confused. You report a bug, raise the priority and then close it. Is the bug not a bug afer all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 15:05:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 15:05:35 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.b4225a9e48ccbbebd6756651ce5f5853@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries -------------------------------------+------------------------------------- Reporter: mtjm | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: arm | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by boo): * version: 7.5 => 7.8.3 * architecture: Unknown/Multiple => arm * milestone: 7.8.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 15:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 15:50:30 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.7027abe731e470c36a16f380cefd2d1a@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): This morning I approached this issue with a fresh perspective and realized that the solutions is quite simple (unless I've missed something). The issue with new LLVMs is that aliases can't point to things that aren't definitions. As it turns out, the only case where we emit aliases pointing to non- definitions is for external symbols where we emit an extern declaration and a corresponding alias. Unless I'm mistaken, there is no reason why both of these are necessary: we only use the alias. So, instead of emitting, {{{ @stg_BCO_info = external global i8 @stg_BCO_info$alias = alias private i8* @stg_BCO_info }}} we should be emitting, {{{ @stg_BCO_info$alias = external global i8 }}} I've implemented this change in my [llvm-3.5-new branch https://github.com/bgamari/ghc/compare/llvm-3.5-new and it appears to work (or rather, the GHC build hasn't failed yet; I also have yet to verify that LLVM 3.4 still works). Of course, there are still nice opportunities for cleaning up TNTC (as discussed in #4213), but at least this fixes the immediate problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 15:51:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 15:51:01 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.0445bd6fe65c5a171364ba60b4ddf6b1@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.13 Component: Compiler | Keywords: (LLVM) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: 9142 | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): This is quite pertinent: ?http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073667.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 15:53:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 15:53:58 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.fef75b74829f20c8a926ff279206b90d@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by artella.coding): Hi, I am a bit confused myself. When I marked it to high, I did not know a way around the issue. However later I found a solution (see http://stackoverflow.com/questions/24838982 /memory-blowing-up-for-strict-sum-strict-foldl-in-ghci) and I closed it (because I didn't want a ticket to be marked as an open bug if it wasn't a bug). Following the comments in http://stackoverflow.com/questions/24838982 /memory-blowing-up-for-strict-sum-strict-foldl-in-ghci I found that the only way that I could run the code without it blowing up in ghci is to run it as follows : {{{ ghci -fobject-code Test }}} '''and''' to have the header : {{{ module Main (main) where }}} What would be your suggestion? Is it a bug? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 17:28:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 17:28:18 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.4238664574e0e93ab56d85178b34c3c1@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately it seems that this approach suffers from undefined references. I haven't had a chance to think about why but I'll have a look tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 17:36:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 17:36:25 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.6c7dbb9c874e2a5a0f0ab508c150077d@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Never mind, of course that won't work: the extern symbols under this scheme would be pointing to non-existent `$alias` symbols. If we instead change the names of the definitions themselves and then allow the aliases to take the actual names, this plan might have a chance of working. Haven't yet thought about what this would require. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 18:00:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 18:00:29 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.99003b070741a3acd16cba146e8e8d5e@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by artella.coding): OK things are a bit clearer now, but I am still not certain as to whether it is a bug or not. If we have : {{{ --Test.hs module Main (main) where import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList main = do print $ result }}} Now if we do : a)First clean all .o and .hi files. b)Now compile as "ghc Test". This creates .hi and .o files. c)Now load into ghci via "ghci Test" d)"longList" is in scope. Therefore unsurprisingly running main blows up. Now if we do the following : a)Clean all .o and .hi files. b)Load into ghci via "ghci -fobject-code Test" c)Now "longList" is not in scope. This time running main does not blow up. I think that Orjan was trying to explain this in http://stackoverflow.com/a/24840786/917635 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 18:06:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 18:06:49 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.220d7ea8e50373ca949675eafe7c44d9@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Not a bug. `longList` is a CAF (e.g. a global not-yet-evaluated constant). When you load it in GHCi and evaluate result, GHC doesn?t know whether you are going to use `longList` again, and has to keep it in memory. But if you compile it is a program, or as a module only exporting `main`, GHC will make `longList` a local definition that, after the evaluation of `Result` is started, can be garbage collected. (With `-O` it will probably fuse it away even, but that is unrelated here.) But thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 19:23:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 19:23:10 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library Message-ID: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Kyle Van Berendonck in [http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html a message on ghc-devs] pointed to [https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 base/GHC/Conc/Sync.lhs] decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type. The constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 19:28:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 19:28:22 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.3b8fbe2b471508879cbb699e93ff7ea6@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by jberthold): * cc: jberthold (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 21:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 21:10:05 -0000 Subject: [GHC] #9334: Implement "instance chains" Message-ID: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- It would be useful to implement a version of "instance chains" [1] in GHC, which would eliminate the need for OVERLAPPING_INSTANCES in most (all practcial?) programs. The idea is that programmers can explicitly group and order instances into an "instance chain". For example: {{{ instance (Monad m) => StateM (StateT s m) s where ... else (MonadTrans t, StateM m s) => StateM (t m) s where ... }}} When GHC searches for instances, the instances in a chain are considered together and in order, starting with the first one: 1. If the goal matches the current instance's head, then this instance is selected and the rest are ignored, as if they were not there; 2. If the goal does not match the current instance's head, AND it does not unify with the current instance's head, then we skip the instance and proceed to the next member of the chain; 3. If the goal does not match the current instance's head, but it does unify with it, then we cannot use this chain to solve the goal. In summary: earlier instances in a chain "hide" later instances, and later instances can be reached only if we are sure that none of the previous instance will match. [1] http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 21:12:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 21:12:58 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.64f4c33f0edaa615d12f337e84bb5d86@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by diatchki): I thought some more about the OVERLAPPING and OVERLAPPABLE idea, but I couldn't come up with examples where I'd want to use that feature. So, for the time being, I'll leave the implementation as is, and document it accordingly. Related to this: having looked at the code for the instance database, I think it would be quite easy to implement "instance chains", which eliminates the need for overlapping instances in pretty much all situations that I've encountered them. I outlined the details in ticket #9334. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 19 23:03:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jul 2014 23:03:46 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.ee040a1b344f362f115b888062fa6638@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: It's still a little fishy that it's treating a missing module declaration differently from the officially equivalent `module Main (main) where`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 01:57:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 01:57:38 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.9b1766dd923af522eb638237a59eefd8@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by brbr): * cc: brooks.brian@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 02:03:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 02:03:14 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.c26416d814904f19a9e479fb33d8c294@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (LLVM) | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by brbr): * cc: brooks.brian@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 06:09:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 06:09:10 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.87348bf8a33332237331e15ec7275888@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Template | Version: 6.8.2 Haskell | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: TH_import_loop Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: m@? (added) Comment: FWIW, I just ran into this very same issue. My use case is identical in structure to goldfire's, but is unrelated to the singletons library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 09:04:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 09:04:11 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.45e056efbedcebbf52cfd32cc7d79ea5@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by artella.coding): If I modify the code above to the following, it blows up and this time using the methods above '''do not''' help : {{{ --Sort.hs module Sort (result) where import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList }}} {{{ --Main.hs module Main (main) where import Sort (result) main = do print $ result }}} Then running with : {{{ ghci -fobject-code Main.hs }}} results in memory blowing up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 11:06:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 11:06:16 -0000 Subject: [GHC] #9335: Add Functor, Applicative, Monad instances for First, Last Message-ID: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This was proposed in 2011 [1] with no serious objections although wasn't implemented until it was again mentioned in 2014 [2]. [1] http://www.haskell.org/pipermail/libraries/2011-January/015552.html [2] http://www.haskell.org/pipermail/libraries/2014-June/023228.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 11:06:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 11:06:43 -0000 Subject: [GHC] #9335: Add Functor, Applicative, Monad instances for First, Last In-Reply-To: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> References: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> Message-ID: <061.ef9178d00db015b54152e4f4250fae7f@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: hvr, ekmett (added) * status: new => patch * component: Compiler => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 11:08:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 11:08:12 -0000 Subject: [GHC] #9335: Add Functor, Applicative, Monad instances for First, Last In-Reply-To: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> References: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> Message-ID: <061.363d6e8c166a211c5c9c3a43088507e7@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Or see https://github.com/bgamari/ghc/tree/first-last-amf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 11:27:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 11:27:30 -0000 Subject: [GHC] #9335: Add Functor, Applicative, Monad instances for First, Last In-Reply-To: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> References: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> Message-ID: <061.66ea0e82044e682ece4fc67e87f46c43@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: https://phabricator.haskell.org/D81| Blocking: Architecture: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => https://phabricator.haskell.org/D81 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 11:27:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 11:27:44 -0000 Subject: [GHC] #9335: Add Functor, Applicative, Monad instances for First, Last In-Reply-To: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> References: <046.369ca69195ad81e00128eb4293d5be2c@haskell.org> Message-ID: <061.e17bf6cd3f762acbe8e75baca46a8246@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: Phab:D81 | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: https://phabricator.haskell.org/D81 => Phab:D81 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 13:33:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 13:33:28 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.878edeab2ccf95a4516e81f13f8f4c16@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:14 scpmw]: > Haven't followed the discussion so much - so LLVM HEAD can alias arbitrary pointers? That's even more flexibility than we had before. So now we could just close this ticket and take another good look at #4213, right? I just realized I never actually addressed this. Unfortunately this ticket is still an active issue: while aliases can alias expressions, these expressions can still only refer to definitions. To restore the LLVM codegen to a functioning state we would need the LLVM people to again allow aliases to declarations as suggested by Reid http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073464.html. I've pinged the thread as Rafael had some reservations to this idea that were apparently never addressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 13:55:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 13:55:14 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.5135b2d049dacbf138d2e3ebe37e3ecc@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > I suspect that adding -O2 to libraries and compiler (we would have to do both) would make validate lower, but I don't know how much; feel free to measure it. I do think validate is too slow already, though, and we should be finding ways to speed it up. I changed the builder for ghcspeed to set `Validating=YES`, and the time to run `make` was reduced by ?. I didn?t measure the time for a whole validate run, I guess I?ll do that separately. But setting that changes more than just `GhcLibHcOpts`, e.g. it disables split objects (increasing binary sizes by a factor of 3.5). Allocation of nofib benchmarks wobble a bit, but significat changes are only on the increasing side (fish, +5%), so for nofib, the release settings seem to be better than the validate setting. (good!) The allocation number of #4801?s test case actually decreases by 4.7%. In total, 7 test cases now get *better* allocation numbers, while only `haddock.base` degrades by more than 1%. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 14:39:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 14:39:34 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.b963c7a5f8d84dd15bf38c508fcdcbbb@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by slomo): The attached patch against 7.8.3 works around this by always putting absolute paths to the .o files into the linker script. Works with gold but should also just work fine with bfd (but I didn't test that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 14:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 14:44:12 -0000 Subject: [GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters Message-ID: <044.1f99437dfb37404e6cbefdee11591c8a@haskell.org> #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The binutils gold detection does not work if it is called via gcc and only selected via commandline parameters (i.e. -fuse-ld=gold). Reason is that the "linker" (actually compiler) is called without its commandline parameters. Attached patch fixes that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 14:51:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 14:51:07 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.8e16731230de236dd637a045a0a59634@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: 7.8.4 Priority: normal | Version: 7.8.1 Component: Driver | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: arm | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by slomo): For allowing to build with gold, ticket #7452 has to be fixed too (includes patch) After that it seems to be possible to build 7.8.3 with gold by setting CONF_GCC_LINKER_OPTS_STAGE1="-fuse-ld=gold" CONF_GCC_LINKER_OPTS_STAGE2="-fuse-ld=gold" and calling configure with --with-ld=ld.gold This assumes that stage0 ghc works out of the box with its configured linker (e.g. the default system linker is still bfd, as is on Debian). And this also requires the patch from ticket #9336 I'm not 100% sure yet if the build will succeed, it's still running. But this brings us one step closer at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 15:18:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 15:18:56 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.497c293a0e58aea6fe3b538cd7a9862e@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 16:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 16:31:15 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.35422a77e80e7f95a3487ece5fef7a8d@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Iavor -- it would be great to see instance chains for real. There are two further observations I'd like to make, though: 1. Instance chains can, I believe, be simulated accurately with closed type families. The encoding is bulky, and I think having real instance chains is much better than what we have in 7.8, but an eager programmer can use closed type families today. For example, Iavor's example could be written {{{ type family ChooseStateMInstance x y where ChooseStateMInstance (StateT s m) s = 0 ChooseStateMInstance (t m) s = 1 class StateM' (n :: Nat) x y where ... instance Monad m => StateM' 0 (StateT s m) s where ... instance (MonadTrans t, StateM m s) => StateM' 1 (t m) s where ... type StateM s m = StateM' (ChooseStateMInstance s m) s m }}} Like I said, it's not pretty, but I believe it works. 2. This doesn't necessarily mean that we'll never need overlapping instances -- instance chains seem to only work when the overlap would be contained only in one module. Some programs require inter-module overlap (say, for a global "default" instance). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 17:43:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 17:43:14 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.fc37350f923ec198f98789f594a09777@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D82 * related: => #8647 Comment: Here's a first [Phab:D82 draft version]. The number of library calls going into GMP (via `ltrace -c`, which btw is a wonderful tool for that) is essentially the same (in some cases slightly lower, as the new code is a bit more clever in some ways). However, I'm seeing improvements as well as regressions in the Nofib results (see Phab:P6). I still need to figure out what the reason is for the rather visible allocation increase in `primetest` (and maybe `kahan` and `bernouilli`). It could be this different approach undoes part of #8647, as we can't so easily optimistically allocate temporary single-limbs on the stack (on the bright side, we've got almost no Cmm code anymore...) Btw, while implementing the code, I would have wanted to write {{{#!hs foreign import ccall unsafe "integer_gmp_mpn_tdiv_q" c_mpn_tdiv_q :: MutableByteArray# s -> ByteArray# -> GmpSize# -> ByteArray# -> GmpSize# -> State# s -> State# s foreign import ccall unsafe "gmp.h __gmpn_divrem_1" c_mpn_divrem_1 :: MutableByteArray# s -> GmpSize# -> ByteArray# -> GmpSize# -> GmpLimb# -> State# s -> (# s, Word# #) }}} However, GHC insisted on having me to write `... -> IO ()` and `... -> IO Word` respectively, thus forcing a boxed/lifted `Word` even though `{-# LANGUAGE UnliftedFFITypes #-}` was in effect. Any chance to have unlifted types allowed for `IO`-like FFI ccalls to reduce the overhead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 18:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 18:08:59 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.c92ff8d2613086be690d5827b4407a86@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): the 7.8 version is here https://github.com/ghc/packages- base/blob/ghc-7.8/GHC/Conc/Sync.lhs#L484-L495 (looks like it was last touched fall 2013 ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 18:16:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 18:16:01 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.ffc87155888073865afddeff237b6c53@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by jberthold): @Carter: Yes, fall 2013 was when the block reason codes were extended. This bug is related to #9003 (modified block reason codes), the respective fix should have changed base back to what it was before (and adding I have put together a fix and a small test for this. Taking this as an opportunity to set up the phabricator environment, I will submit the fix there for HEAD. The respective fix for ghc-7.8.3 will be in libraries/base, a patch for base is attached (and the test case Haskell). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 18:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 18:39:12 -0000 Subject: [GHC] #5401: LANGUAGE pragma parser nit In-Reply-To: <042.ae92bdd8a2d3bac0338a8b988fbf5876@haskell.org> References: <042.ae92bdd8a2d3bac0338a8b988fbf5876@haskell.org> Message-ID: <057.076570fe4f810de07fac5c6e09fb8865@haskell.org> #5401: LANGUAGE pragma parser nit -------------------------------------+------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 (Parser) | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > A language pragma like > {{{ > {-# LANGUAGE > TypeOperators, > FlexibleContexts #-} > }}} > parses just fine but > {{{ > {-# LANGUAGE > TypeOperators, > FlexibleContexts > #-} > }}} > doesn't, saying: > {{{ > Cannot parse LANGUAGE pragma > Expecting comma-separated list of language options, > each starting with a capital letter > }}} > An OPTIONS pragma, on the other hand, accepts either format without > complaint. New description: Language pragmas like {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} or {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} parse just fine but {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} doesn't (note the missing spaces before the closing `#-}`), saying: {{{ Cannot parse LANGUAGE pragma Expecting comma-separated list of language options, each starting with a capital letter }}} An OPTIONS_GHC pragma, on the other hand, accepts either format without complaint. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 18:41:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 18:41:25 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.730c50731d2b365e4d6eff35efef51c8@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I just timed two plain `./validate` runs. The first with the current settings (`-O`): {{{ $ cat /tmp/validate-O.txt Command exited with non-zero status 1 3573.46user 204.47system 36:13.68elapsed 173%CPU (0avgtext+0avgdata 1534340maxresident)k 76944inputs+17408472outputs (255major+249188896minor)pagefaults 0swaps }}} The second one with `GhcLibHcOpts += -O2 -dcore-lint` in `k/validate- settings.mk`: {{{ Command exited with non-zero status 1 3675.64user 209.70system 37:10.83elapsed 174%CPU (0avgtext+0avgdata 1535452maxresident)k 1048inputs+18010496outputs (18major+249644503minor)pagefaults 0swaps }}} Yes, it does take longer. But hardly significantly. Hence I?m in favour of setting `GhcLibHcOpts += -O2` for validate runs, bringing our validation closer to what we release, and also making a `make -C testsuite` in non-validate non-customized tree to yield the same performance numbers (at least for non-compiler-performance-tests). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 18:47:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 18:47:20 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.93f44ecc1a6ad68bba7a05454ed8388b@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by diatchki): I think that rwbarton's comments above explain quite well why danilo2's program is incorrect, and GHC correctly rejects it. No matter which rule we use to ''implement'' the consistency check for the functional- dependency, it is crucial that the rule is ''sound''. No sound rule will accept that program, because it violates the ''specification'' for functional dependencies. As for `DysfunctoinalDependencies`: I have no idea what that means, or how it is supposed to work. Is there a write-up or a spec that explains the extension? I'll refrain from commenting further until I understand the concept, but I do think that if it gets implemented, it should use a different syntax from FDs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 19:16:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 19:16:58 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.203a4bf2114e44acc73d9990745f0057@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by diatchki): Actually, there is no requirement that an instance chain be closed and, in fact, I was thinking of just starting with open ones. Of course, one could do the same sort of encoding using open TFs. However, the encoding does not fully subsume instance chains. For example, using instance chains I could write instances like these: {{{ instance Show (MyContainer Char) where ... else Show a => Show (MyContainer a) where ... }}} I couldn't do this with the encoding because the `Show` class does not have the extra parameter that would be needed. Not only is the encoding not pretty (imagine the type error you'd get for a missing instance), but using it requires enabling some fancy machinery (TFs, which pulls in FC, and reasoning about equality, etc.). Of course, we already have all this, but somehow it feels like implementing an easy idea, using some very advanced tools and, perhaps, it is better if we do not entangle these two. As for point (2), instance chains pretty much cover all the situations where ''I'' have wanted to use overlap (note the emphasis on ''I'' :-). For example, I wouldn't provide a global "default" instance, because it is too error prone. For the sake of concreteness, here is what I am referring to: {{{ class MyShow a where myShow :: a -> String -- default instance instance {-# OVERLAP #-} MyShow a where myShow _ = "(can't show this)" showInParens x = "(" ++ myShow x ++ ")" }}} In this example, `showInParens` would very likely not do what we intended, because it will commit to the "default" instance prematurely. Of course, this is just one example, but I think it is fairly representative of the difficulties inherent in using cross-module overlapping instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 19:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 19:18:10 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.c9322a8add159a4595951569cb905bd6@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): @diatchki please do not base your opinion on the examples above - they are a little old and of course, they do not obey some basic principles. The idea with `-XDysfunctionalDependencies` is just to lift both the Paterson Conditions and the Coverage Condition - something `-XDysfunctionalDependencies` claims to do (according to documentation), but does not (as simonpj noticed above). When using this extension you can just give hints to typechecker and compile programs like the one I've posted on https://phabricator.haskell.org/D69 : {{{#!haskell {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE DysfunctionalDependencies #-} class CTest a b | a -> b where ctest :: a -> b data X = X instance Monad m => CTest X (m Int) where ctest _ = return 5 main = print (ctest X :: [Int]) -- [5] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 20:06:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 20:06:13 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.8ffc20962e3ee39b657666df1ffbcc53@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: jberthold Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: D83 | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by jberthold): * owner: => jberthold * differential: => D83 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 20:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 20:10:54 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.8d23fb60d75c1c6b1e86fefce8fa0a27@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: jberthold Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D83 | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by jberthold): * status: new => patch * differential: D83 => Phab:D83 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 20:51:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 20:51:05 -0000 Subject: [GHC] #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM In-Reply-To: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> References: <045.febef025f59f8d7ebeb4dcc920991d5a@haskell.org> Message-ID: <060.9959c041c0239e7cf518db0090557e18@haskell.org> #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM -------------------------------------+------------------------------------- Reporter: vsajip | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Keywords: BOM Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #1744 | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * related: => #1744 Old description: > The file > > {{{ > #!/usr/bin/env runhaskell > main = putStrLn "Hello, world!" > }}} > works on Windows as expected: > > {{{ > C:\Temp>runhaskell hello.hs > Hello, world! > }}} > However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for > example, sometimes adds this BOM to files), an error occurs: > > {{{ > C:\Temp>runhaskell hello2.hs > > hello2.hs:1:1: parse error on input `#!/' > }}} > > I'm using the Haskell Platform 2011.4.0.0. > > I believe that runhaskell/runghc should handle the presence of a BOM > correctly; some Windows programs insert a BOM unbeknownst to the user. > > This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit > and 64-bit). New description: The file {{{ #!/usr/bin/env runhaskell main = putStrLn "Hello, world!" }}} works as expected: {{{ C:\Temp>runhaskell hello.hs Hello, world! }}} However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for example, sometimes adds this BOM to files), an error occurs: {{{ C:\Temp>runhaskell hello2.hs hello2.hs:1:1: parse error on input `#!/' }}} I'm using the Haskell Platform 2011.4.0.0. I believe that runhaskell/runghc should handle the presence of a BOM correctly; some Windows programs insert a BOM unbeknownst to the user. This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit and 64-bit). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:15:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:15:31 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.52cc82a9f4f28585ef13c8aab7d0a3b0@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by blitzcode): * version: 7.6.3 => 7.8.3 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:17:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:17:27 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.2d61a440022b83de56c07a869b3c0ea3@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by blitzcode): This bug still exists in 7.8.3 exactly as described in the initial report -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:20:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:20:54 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.20bcb3d4ff646bf1193b5f07775be8dc@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by carter): i believe this should be fixed in HEAD. could you test there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:48:59 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.a904a4c5cbe764c850a0593dbbebad8f@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by jrp): It may also help to run validate with a default -j8 or some such. The tests and compilations are all more or less single core and most developers will have at least 8 cores. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:56:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:56:30 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.af60c7516e9ded7c78408f661149d477@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D70 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"18b2c46773eccb974bdd042a2f400edd23e193d7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="18b2c46773eccb974bdd042a2f400edd23e193d7" Add PolyKinds extension to Data.Monoid Summary: Carl Howells pointed out[0] that the `Monoid` instance for `Data.Proxy.Proxy` is only defined for types with kind *. This is a very mild change. Furthermore, Edward Kmett revealed[1] that it was supposed to be there all along -- the extension simply got lost in commit 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11, as pointed out by Adam Vogt[2]. This used to be correct in GHC 7.6, so this commit fixes a regression. This addresses #9317. [0] . [1] . [2] . Signed-off-by: Alexander Berntsen Test Plan: See [0] Reviewers: austin, hvr, ekmett Reviewed By: austin, hvr, ekmett Subscribers: phaskell, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D70 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:56:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:56:31 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user In-Reply-To: <044.7996ef569ec65e1751223f37063032df@haskell.org> References: <044.7996ef569ec65e1751223f37063032df@haskell.org> Message-ID: <059.c4768bdac8cd3ed466fd61fff7df96ef@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D75 | Operating System: POSIX Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fb936e0db55b0522ddcabd39833c99c7c2871170/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb936e0db55b0522ddcabd39833c99c7c2871170" Make GHCi permissions checks ignore root user. Summary: As a security precaution, GHCi helpfully refuses to run a .ghci file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways. This means that .ghci files installed in a global location, say under /usr/local/, can now be read. Fixes #9324 Test Plan: ``` $ sudo touch .ghci $ ghci ``` Notice that the warning about the file being owned by someone else is now gone. Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, carter, nomeata, relrod Projects: #ghc Differential Revision: https://phabricator.haskell.org/D75 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:56:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:56:31 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.43d91a71ed4cd6a7e05e4daf16b18810@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"021b7978d14799bae779907faf7490cfd21b3f46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="021b7978d14799bae779907faf7490cfd21b3f46" driver: use absolute paths in ld scripts (#7452) Patch contributed by slowmo. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:57:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:57:33 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user In-Reply-To: <044.7996ef569ec65e1751223f37063032df@haskell.org> References: <044.7996ef569ec65e1751223f37063032df@haskell.org> Message-ID: <059.46cb4ea72d8ce10509dab6bed4e2d313@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Differential Revisions: Phab:D75 | Operating System: POSIX Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:57:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:57:58 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.2d036301718de2c3380fe6e864589455@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: fixed | Operating System: Unknown/Multiple Differential Revisions: Phab:D70 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:58:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:58:23 -0000 Subject: [GHC] #9317: Add PolyKinds extension to Data.Monoid In-Reply-To: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> References: <047.9abe0fabe4719b12cafdc7be8424e08d@haskell.org> Message-ID: <062.6a643ff81db735361954e387c2d03244@haskell.org> #9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: fixed | Operating System: Unknown/Multiple Differential Revisions: Phab:D70 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 21:58:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 21:58:30 -0000 Subject: [GHC] #9324: GHCi permission checks should ignore root user In-Reply-To: <044.7996ef569ec65e1751223f37063032df@haskell.org> References: <044.7996ef569ec65e1751223f37063032df@haskell.org> Message-ID: <059.d51ce5931316d27c5c3ef2924e6e4d18@haskell.org> #9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Differential Revisions: Phab:D75 | Operating System: POSIX Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:02:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:02:44 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.b991a92a1ddb1ccc2f3f4ba94120bd2f@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): The current default is `-j2`, I guess it could be updated. But this is digressing from what this ticket is about (making `validate` settings and default settings agree more, if possible). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:12:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:12:30 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List Message-ID: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Easy (less Blocking: | than 1 hour) | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`: {{{ -- | Sort a list using a key on each element. This implements the -- decorate-sort-undecorate paradigm, also called a Schwarzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> (f x, x)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:16:23 -0000 Subject: [GHC] #9338: Some ghc options do not seem to be documented: Message-ID: <042.e12c509cb214268f1f7773d34219ca1f@haskell.org> #9338: Some ghc options do not seem to be documented: -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- ghc --show-options comes up with options that I could not find in the manual. For example -parallel, -smp, -mavx. Would it be possible to * come up with an alphabetical list in the manual? * have an option that picked the best combination of options for the cpu on which you are running? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:29:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:29:37 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.1492908276ddadf1032686d8cae90448@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.8.3 Priority: normal | Keywords: Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Resolution: | Test Case: Differential Revisions: | Blocking: Architecture: | Unknown/Multiple | Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): It is "Schwartzian". ;) Otherwise, this passed the libraries process easily and folks on the committee who were asked about it were all in favor, so it looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:43:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:43:21 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.38f3404697d8497df9207e4d529158fa@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): First the good news: I have figured out what LLVM code we need to generate to satisfy LLVM's type system. An annotated example can be found here https://github.com/bgamari/ghc-llvm/blob/master/test.ll . Unfortunately, this seems to be a bit of a departure from our current approach. Quite a bit of code needs to be touched and I haven't yet been able to find a clean way to factor out the details of the alias generation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 20 22:53:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jul 2014 22:53:56 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.96a14240e780ba0773e18081faefc2a9@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by jrp): Understood, but I thought that there was some hesitation about using more expensive validate settings because of the running time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 00:21:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 00:21:29 -0000 Subject: [GHC] #9339: last is not a good consumer Message-ID: <045.684d85de4a358347b6875763cb59223d@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The profiler indicates that `print $ last [(1::Int)..10^7]` (compiled with -O2) allocates around 8*10^8 bytes. Using the Henning Thienemann-inspired {{{ myLast = fromJust . foldr (\x -> Just . maybe x id) Nothing }}} (based on his code for viewR/unsnoc) reduces allocation by about half at the cost of some extra work. What we really want, I believe, is for `last` to fuse with the producer in a fashion that allows the Ints to be unboxed, eliminating all the allocation. I have no idea if this will fall out of the general fusion work planned for 7.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 01:20:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 01:20:12 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.2dfcb2018415a1412a4b5716a9567524@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 diatchki]: > No matter which rule we use to ''implement'' the consistency check for the functional-dependency, it is crucial that the rule is ''sound''. Why? As Simon notes above, if FDs are unsound, the programs that we get are still type-correct. There may be class coherence issues and/or fragile compilation (that is, changes in behavior that stem from seemingly- insignificant changes in code), but not outright failure. (By outright failure, I mean "seg fault" or `unsafeCoerce`.) And, in comment:19, I believe danilo2 meant to say that the documentation claims that `-XUndecidableInstances` lifts the Paterson and coverage conditions, but that the documentation is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 01:22:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 01:22:59 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.679ab91121de0eb840805a1122015f41@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.8.3 Priority: normal | Keywords: Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Resolution: | Test Case: Differential Revisions: | Blocking: Architecture: | Unknown/Multiple | Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by JohnWiegley): Ack, my German teacher just rolled in her grave. Thanks for catching that. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 01:32:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 01:32:47 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.862eab965d968c5318ebce6ae76e7f13@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): I finally have a brutally hacked implementation working with both LLVM 3.4 and HEAD (r213478). Unfortunately, it's nowhere near merge-worthy. In fact, it's terrible. That being said, it (https://github.com/bgamari/ghc/compare/llvm-3.5-new) works and may serve as a model if someone has some time to do some refactoring. Otherwise I'm afraid my weekend is now over so I'll have to put this down for a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 01:34:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 01:34:29 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.0b272e610d276a024fa4eced1098600e@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Difficulty: Unknown | at runtime Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 01:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 01:39:52 -0000 Subject: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite In-Reply-To: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> References: <045.baf39684c1ad6f53c42a607914cc93f4@haskell.org> Message-ID: <060.f94186071325e3437842c76fde02fa15@haskell.org> #4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.13 Component: Compiler | Keywords: (LLVM) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: 9142 | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): After reading Rafael's suggestion more closely it's not at all clear that this will do what we want (namely, it's unclear how one would actually attach code to the defined symbol). I've asked for further clarification although I suspect we'll need need to use LLVM's `symbol_offset` support to make this work. Hopefully we'll be able to get them to amend the semantics of this attribute to be more convenient for our purposes before 3.5 is cut. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 02:02:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 02:02:11 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.c626c8d8d50b9222dd2b84457299680e@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): To describe the approach a bit more, I've inverted the roles of the aliases and symbol definitions. That is, symbol definitions take names of the form `@symbol$def` whereas `@symbol` is defined as an alias. The `@symbol` aliases have external linkage when appropriate, ensuring they are available for external references which can simply use an normal `@symbol = external global` declaration. This in effect moves the aliases from the point of use to the point of definition, satisfying LLVM's prohibition of aliases of declarations. As I've currently implemented it this logic is scattered through the backend (although the fact that data and functions are so distinct in LLVM doesn't help things). Hopefully a bit more reflection will produce a more coherent solution. Ultimately I may hold off on this until after we know how we will fix TNTC as this will be another major refactoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 02:26:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 02:26:28 -0000 Subject: [GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.f08756193c7f75c9ec0ef88971ae7e4a@haskell.org> #9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 4213 Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately the branch fails to build GHC itself due to overlapping symbol names when compiling raw cmm source. I suspect the problem is excessive visibility, although I'm not sure where. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 06:22:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 06:22:05 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop Message-ID: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (CodeGen) | Differential Revisions: Keywords: primop clz | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: {{{#!hs -- | Compute base-2 log of 'Word#' ?-- ?-- This is internally implemented as count-leading-zeros machine instruction. ?foreign import ccall unsafe "integer_gmp_word_log2" wordLog2# :: Word# -> Int# }}} {{{#!c HsWord integer_gmp_word_log2(HsWord x) ?{ ?#if (SIZEOF_HSWORD) == (SIZEOF_INT) ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; ?#elif (SIZEOF_HSWORD) == (SIZEOF_LONG) ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; ?#elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; ?#else ?# error unsupported SIZEOF_HSWORD ?#endif ?} }}} Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop ({{{clz# :: Word# -> Int#}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 06:25:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 06:25:04 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.3b1041ae7ff7f5940b69807f2fa958b2@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (CodeGen) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Old description: > From a draft for #9281, I had to use a C FFI and using a gcc/clang > `__builtin` to get access to the > [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: > > {{{#!hs > -- | Compute base-2 log of 'Word#' > ?-- > ?-- This is internally implemented as count-leading-zeros machine > instruction. > ?foreign import ccall unsafe "integer_gmp_word_log2" > wordLog2# :: Word# -> Int# > }}} > > {{{#!c > HsWord > integer_gmp_word_log2(HsWord x) > ?{ > ?#if (SIZEOF_HSWORD) == (SIZEOF_INT) > ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; > ?#elif (SIZEOF_HSWORD) == (SIZEOF_LONG) > ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; > ?#elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) > ? return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; > ?#else > ?# error unsupported SIZEOF_HSWORD > ?#endif > ?} > }}} > > Since a `clz`-like operation should be available on most cpus GHC should > expose that as a primop ({{{clz# :: Word# -> Int#}}}). New description: From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: {{{#!hs -- | Compute base-2 log of 'Word#' -- -- This is internally implemented as count-leading-zeros machine instruction. foreign import ccall unsafe "integer_gmp_word_log2" wordLog2# :: Word# -> Int# }}} {{{#!c HsWord integer_gmp_word_log2(HsWord x) { #if (SIZEOF_HSWORD) == (SIZEOF_INT) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; #else # error unsupported SIZEOF_HSWORD #endif } }}} Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop ({{{clz# :: Word# -> Int#}}}). -- Comment (by hvr): (remove hidden Unicode characters in code blocks) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:15:06 -0000 Subject: [GHC] #9341: Evaluate default CPUs setting for validate Message-ID: <046.b9cefa8bb3e5226f52c77645c82efc6d@haskell.org> #9341: Evaluate default CPUs setting for validate -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This is a fork off #9315:comment 16. `./validate` runs `-j2` (i.e. CPUS=1). I guess most developers these days have a stronger system that would allow for more cores to be used. This ticket should discuss if this default should changed to something higher, or possibly something dynamic. On Linux, there is the command `nproc`, part of coreutils, for that ? is that also provided by our default windows environment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:15:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:15:40 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.05718f14414bf6d59c3049f4abb330e7@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Of course improving validate time is desirable, I put your suggestion at #9341. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:19:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:19:32 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.943583dfb44dad1d7dc93535bfa65dd8@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): I think we are all agreed that type inference must be sound. But, as mentioned above, "sound" for GHC means that * If the program passes the type checker, the elaborated Core program satisfies Core Lint. * If a program satisfies Core Lint, it enjoys preservation and progress (of the Core program); it cannot seg-fault. In operational terms I think the change proposed is well specified: look at comment:14, especially the user manual section and the three bullets at the end of the comment. The question at issue is not soundness, but rather * Precisely which programs satisfy the type inference engine? * Is type inference complete? I.e. does it find a type for every program specified by the first bullet? * Is type inference robust? I.e. can a small change in the program (e.g. swapping the order of arguments to a function) make the difference between type inference succeeding and failing? * Is the elaborated program coherent? I.e. is it well specified what the result of running that program will be? The effect of `-XDysFunctionalDependencies` on these aspects of type inference is not well understood. But it seems a much more benign form of allowing the programmer saying "trust me please" than `unsafeCoerce`, for example, because the soundness guarantee is not threatened. The `-XUndecideableInstances` flag is somewhat similar, in that it continues to guarantee soundness, but allows type inference to diverge. This could perfectly well be a per-instance pragma, rather than a module- wide language extensions. Something like {{{ instance {-# DYSFUNCTIONAL#-} Monad m => CTest X (m Int) where ... }}} That might be better, actually; it's more precisely targeted. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:25:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:25:29 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.5688c2896558622f6e86372c63afd393@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. It would be good to articulate the goal more explicitly. Is it primarily to improve interop in some way? How does it improve interop? Or is it to do with performance -- unsafe foreign calls are vastly more efficient than safe ones? Why do `integer_gmp_mpn_tdiv_q` etc need to be IO-ish at all? Can't they be pure functions? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:32:21 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.b829f6732889a9b1de97a2e65d576e8c@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): There is a difficult tension here, described in Chapter 23 of my [http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj- book-1987/index.htm 1987 book], namely the tension between sharing computation and saving space. I do not know of any comprehensive answer. The problem tends to bite less when (as is commonly the case) numbers like `1000000` don't appear in your program but rather are computed from the input or the command line flags. But it's still definitely a problem (e.g. with `[1..]`.) A possible solution might be to revert any CAFs that are retaining a great deal of space, by turning them back into their un-computed form. (Of course, their uncomputed form might retain a great deal of space too!) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:33:53 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.4d968734c4908f799aea6aae3987f76b@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): What general fusion work are you referring to? I only know about the improvements for fusing foldl, which doesn?t seem to apply here. Although maybe it could. How about this definition: {{{ myLast2 :: [a] -> a myLast2 = foldl (\_ x -> x) undefined }}} While `last` yields 800051648 bytes, and `myLast` yields 560084432 bytes, this runs in 51648 bytes (i.e. it fuses completely). Admitted, the resulting code looks almost stupidly efficient (at least if I write `10^7` as `10000` ? I?m unjustifiably surprised that that is not constant-folded): {{{ Rec { $wgo $wgo = \ w_s3Aj -> case w_s3Aj of wild_Xf { __DEFAULT -> $wgo (+# wild_Xf 1); 10000000 -> 10000000 } end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:49:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:49:24 -0000 Subject: [GHC] #9279: Optimisation bug In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.0b1fc3f5108a972db4430c00fd1f1891@haskell.org> #9279: Optimisation bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: nicolas.frisby@? (added) Comment: OK I can see what is going on; it is more or less as you say. We have something like {{{ let worker = \x. BIG in let {-# INLINE wrapper #-} wrapper = \y. ...worker.... in ...map wrapper xs.... }}} (Technically, the wrapper has a "stable inlining" which I have not written above, which is a copy of the body of the wrapper.) Now, GHC is (in general rightly) unhappy about inlining `worker` in `wrapper`'s rhs, even though there is currently just one textual occurrence of `worker`, because there might (now or in the future) be many occurrences of `wrapper`, and the INLINE pragma means we'll make a copy of `wrapper`'s rhs at each occurrence. However, in this case, `wrapper` is not inlined because it's not applied to anything, so nothing is gained. But something is lost. I can see various possible solutions: * Lambda-lift local function definitions, late in the pipeline. This is something Nicolas Frisby was working on, with promising results, but he sadly he never completed the work. I'm copying him on this ticket. * Towards the end of the pipeline, forget that wrappers are special by discarding their INLINE pragmas. This is a bit delicate; I think you would ''not'' want to do this for things marked INLINE by the programmer. And certainly not for top-level things either (else you'd defeat the entire w/w idea). I wonder how often this happens. Might not be hard to find out; how often does a local function definition with an INLINE pragma appear in the final Core? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 07:50:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 07:50:11 -0000 Subject: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation (was: Optimisation bug) In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.40e9048ecce4a3237236b209e750bfa9@haskell.org> #9279: Local wrapper function remains in final program; result = extra closure allocation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:01:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:01:27 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.fd69482a8db8eaebbba6a877b479d98f@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 nomeata]: > What general fusion work are you referring to? I only know about the improvements for fusing foldl, which doesn?t seem to apply here. I was under the impression (possibly bogus) that the `foldl` fix involved some new transformation that could have other effects. > Although maybe it could. How about this definition: > > {{{ > myLast2 :: [a] -> a > myLast2 = foldl (\_ x -> x) undefined > }}} > > While `last` yields 800051648 bytes, and `myLast` yields 560084432 bytes, this runs in 51648 bytes (i.e. it fuses completely). That looks wonderful. Is it certain to be changed to a `foldl'` in cases where it ''doesn't'' fuse? > Admitted, the resulting code looks almost stupidly efficient (at least if I write `10^7` as `10000` ? I?m unjustifiably surprised that that is not constant-folded): Imagine the confusion if it were! Yes, `map f [m..n] !! p` ''could'' be optimized to O(1) whenever `m` has a known-sane type, but then all the newbies and half the oldies would get mixed up when little changes had radical performance impacts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:08:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:08:21 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.9bd3e62334625a7974e14fb07ba724db@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Some thoughts * The instance chains described in the instance-chain paper are much more elaborate than your proposal here; in particular they involve backtracking search and a "fails" possibility. I imagine that is a deliberate narrowing of the specification on your part. * The behaviour you specify for instance chains is, I think, precisely what GHC does for overlappping instances ''when they are all declared in the same module''. See the bullets at the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5 in the user manual]. I grant that putting all the overlapping equations together in one place is clearer, just as with closed type families. But you have the behaviour you want right now, I think. * I think you are arguing that we should ''replace'' overlapping instances with instance chains. That would render illegal any program that uses overlaping instnaces spread across modules. I suspect that would make many people cry, so we'd end up with both. If I have this right, its just a question of whether to support a chained syntax. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:09:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:09:48 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.83a0fd74bc1615c78ac8208e699e7465@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > That looks wonderful. Is it certain to be changed to a foldl' in cases where it doesn't fuse? Hopefully not. `foldl'` would force the accumulator, which we do *not* want here (otherwise the `undefined` would be forced, or `last [undefined, 1]` would not work). I didn?t do further testing with that idea, it just crossed my mind. It maybe the that this implementation is only good when fusing works ? would you mind trying to find out? In that case one would have to do the `replace, try to fuse, replace back` trick (which might be tricky with `foldl` itself getting inlined). Or maybe it is possible to use `foldl` and wrap the argument in a `Id`, so that forcing does the right thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:11:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:11:03 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.5a2dd78b9f64c11f6c37253c632f57a1@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): As I say on the other ticket, I think it'll be a hard sell to ''replace'' overlapping instances with instance chains. So I'd still really like to get the per-instance `{-# OVERLAPPING, OVERLAPPABLE #-}` pragmas proposed above. Would you still be willing to do that? Or, if not, would someone else? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:11:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:11:54 -0000 Subject: [GHC] #9150: libraries/time: parseTime barfs on leading space in format string In-Reply-To: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> References: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> Message-ID: <057.cf62aeada9d7e73eb5f1e5680a0fb4d7@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string -------------------------------------+------------------------------------- Reporter: mjo | Owner: Ashley Yakeley Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.2 (other) | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by Ashley Yakeley): * owner: => Ashley Yakeley Comment: This is awkward. The problem is that `parseTime` discards leading and trailing spaces in the input string when formatting. The obvious solution is to discard leading spaces in the format string. But here's a more difficult case: {{{ parseTime defaultTimeLocale "%Q " " " :: Maybe LocalTime }}} `%Q` matches the empty string, so one would expect this to match. However, `parseTime` discards leading spaces, `%Q` matches the empty string, and the following space can't be matched. Alternatively, instead of skipping initial spaces with `skipSpaces`, one can parse them with `skipMany (satisfy isSpace)`. But now this gives `Nothing`: {{{ parseTime defaultTimeLocale "%k" " 8" :: Maybe LocalTime }}} This ends up parsing two ways: the first when initial skipping grabs the space, and the second when `%k` grabs the space. They end up with the same value, but currently we need exactly one parse for `parseTime` to give a `Just` value. Another alternative would be to drop skipping of leading and trailing spaces. This would make the behaviour of the parsing functions more predictable. However, the current behaviour has been there since time-1.1 from 2007, so programs that depend on it will fail with stricter functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:19:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:19:52 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.2b3e63326e60a8c10c31f023706a72d1@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): If we change validate to use GhcLibHcOpts=-O2 and update the tests to match, then * validate takes a minute longer * the tests now fail with a `quick` build (which we recommend for development, and I generally use) * the compiler is still not built with -O2 So I'm not convinced this is a win. BTW, on the question of -j setting, the usual way is to say `CPUS=8 ./validate` if you have an 8-core machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:31:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:31:13 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.c8775b7a10ba0a99c06ba66655486124@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): See also #9267 for an interesting example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:34:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:34:22 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied In-Reply-To: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> References: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> Message-ID: <061.10305134f202adba55a04965083406a9@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting example. See all the discussion on #8634. The interesting thing here is that (using the vocabulary of #8634) * The initial error message might suggest `-XDysFunctionalDepenencies` * Adding `-XDysFunctionalDependencies` would yield the error in GHC 7.6 * Adding the suggested context to the instance declaration would remove the need for `-XDysFunctionalDependencies` again! If we implement the `DYSFUNCTIONAL` thing on a per-instance basis, as #8634 suggests, we should also warn when it is used but is not necessary. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:35:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:35:09 -0000 Subject: [GHC] #9341: Evaluate default CPUs setting for validate In-Reply-To: <046.b9cefa8bb3e5226f52c77645c82efc6d@haskell.org> References: <046.b9cefa8bb3e5226f52c77645c82efc6d@haskell.org> Message-ID: <061.d5770eb5ec85f5c16dbea10917857774@haskell.org> #9341: Evaluate default CPUs setting for validate -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Simon M. writes: > BTW, on the question of -j setting, the usual way is to say CPUS=8 ./validate if you have an 8-core machine. That?s what I learned, but not immediately. I agree with jrp that the default could be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:36:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:36:18 -0000 Subject: [GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI In-Reply-To: <042.a93530e65a57f7e254d144435628d197@haskell.org> References: <042.a93530e65a57f7e254d144435628d197@haskell.org> Message-ID: <057.7c0cbc4092db4136eed0f9089f0107f5@haskell.org> #9274: GHC panic with UnliftedFFITypes+CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => igloo Comment: Igloo, you are the man who implemented the `CApi` stuff. Might you look into this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:36:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:36:24 -0000 Subject: [GHC] #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8); ` In-Reply-To: <042.61b5d8d63186bd136b03c5418b6145b5@haskell.org> References: <042.61b5d8d63186bd136b03c5418b6145b5@haskell.org> Message-ID: <057.b6091ede6e27c114399d63c843337e4b@haskell.org> #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:44:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:44:55 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.eabbeb69bacf664950fb60f81931a535@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: simonmar (added) Comment: Replying to [comment:5 simonpj]: > Terrific. It would be good to articulate the goal more explicitly. Is it primarily to improve interop in some way? How does it improve interop? Or is it to do with performance -- unsafe foreign calls are vastly more efficient than safe ones? Are you referring to allowing unlifted types as return values in non-pure calls? > Why do `integer_gmp_mpn_tdiv_q` etc need to be IO-ish at all? Can't they be pure functions? because those operations write into `MutableByteArray#` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 08:47:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 08:47:29 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.c9a5fcd0ea5d2cfb4fb0ce5badd22440@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > validate takes a minute longer Out of more than half an hour. It?s not like validate is fast enough so that people can actually sit and watch it. And no matter whether its 36 or 37 minutes, I guess most will stop running validate themselves and rather leave that to Phabricator or other CI stuff, precisely because validate takes so long and its convenient to let someone else do it for you. > the tests now fail with a quick build (which we recommend for development, and I generally use) True. But development trees are inherently unusable, as people might have all kinds of settings there (`-O`, `-DDEBUG` etc.) that invalidate performance numbers. I never paid attention to them for that reason, unless I was doing a clean validate run in a separate checkout. Isn?t running validate in the development tree discouraged anyways? > the compiler is still not built with -O2 True, but one step at a time. (I?ll time this change later, probably over lunch.) You say `quick` is recommended; I thought `devel2` is recommended and that?s what I use and recommend. And there will be much more variation in people?s development trees settings, it?s hard to aim for them. What we can aim for are our two well-defined settings: The default (i.e. what we release) and validate. I?m arguing that we should unify these two as much as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 09:12:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 09:12:44 -0000 Subject: [GHC] #9342: Branchless arithmetic operations Message-ID: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- While working on #9281 I noticed sub-optimal code generation for common arithmetic operations on `Int`. Below are some examples of code generation, where the branchless versions may be desirable on modern CPUs: = `abs` {{{#!hs -- base version absI# :: Int# -> Int# absI# i# = i'# where !(I# i'#) = abs (I# i#) -- optimized version optAbsI# :: Int# -> Int# optAbsI# i# = (i# `xorI#` nsign) -# nsign where -- nsign = i# <# 0# nsign = uncheckedIShiftRA# i# (WORD_SIZE_IN_BITS# -# 1#) }}} results in {{{#!asm absI#_info: _c1To: testq %r14,%r14 jge _c1Tx _c1Ty: movq %r14,%rbx negq %rbx jmp *(%rbp) _c1Tx: movq %r14,%rbx jmp *(%rbp) optAbsI#_info: _c1SX: movq %r14,%rax sarq $63,%rax movq %r14,%rbx xorq %rax,%rbx subq %rax,%rbx jmp *(%rbp) }}} = `signum` {{{#!hs sgnI# :: Int# -> Int# sgnI# i# = i'# where !(I# i'#) = signum (I# i#) optSgnI# :: Int# -> Int# optSgnI# x# = (x# ># 0#) -# (x# <# 0#) }}} {{{#!asm sgnI#_info: _c27W: testq %r14,%r14 jl _c283 _c284: testq %r14,%r14 jne _c28a _c28b: xorl %ebx,%ebx jmp *(%rbp) _c283: movq $-1,%rbx jmp *(%rbp) _c28a: movl $1,%ebx jmp *(%rbp) optSgnI#_info: _c26P: testq %r14,%r14 setl %al movzbl %al,%eax testq %r14,%r14 setg %bl movzbl %bl,%ebx subq %rax,%rbx jmp *(%rbp) }}} = `compare` {{{#!hs cmpI# :: Int# -> Int# -> Int# cmpI# x# y# = dataToTag# (compare (I# x#) (I# y#)) -- returns 0, 1 or 2, can be fed to tagToEnum# :: Ordering optCmpI# :: Int# -> Int# -> Int# optCmpI# x# y# = 1# +# (x# ># y#) -# (x# <# y#) }}} {{{#!asm cmpI#_info: _c25s: cmpq %rsi,%r14 jl _c25z _c25A: cmpq %rsi,%r14 je _c25M _c25N: movl $2,%ebx jmp *(%rbp) _c25z: xorl %ebx,%ebx jmp *(%rbp) _c25M: movl $1,%ebx jmp *(%rbp) optCmpI#_info: _c24N: cmpq %rsi,%r14 setl %al movzbl %al,%eax movl $1,%ebx subq %rax,%rbx cmpq %rsi,%r14 setg %al movq %rbx,%rcx movzbl %al,%ebx addq %rcx,%rbx jmp *(%rbp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 09:29:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 09:29:39 -0000 Subject: [GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied In-Reply-To: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> References: <046.5fa88da4adf3eafbdc66687875e23aec@haskell.org> Message-ID: <061.6ae00dd32c18d489679e6307f4f164b8@haskell.org> #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by danilo2): @simonpj: This is exactly what I'm doing right now. If I migh suggest one thing - maybe it would be better to just report to the user 2 separate errors at once? One about not met liberal coverage condition and the second analogous to the one known from ghc-7.6? This just saves a lot of time with adding and removing flags :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 09:31:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 09:31:02 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.c9b225aa4b7b769a55c47dfe14dfc5de@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): @goldfire, you are right - I fixed my comment, thank you :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 09:33:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 09:33:43 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.01c950711c66ea7517a481eefe6a7f4f@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by sulzmann): Some brief comments regarding the various conditions/flags. * Paterson Conditions and the Coverage Condition (plus the FD Consistency Condition) The above guarantee sound and decidable type inference. In CHR speak, termination and confluence. Confluence effectively means that we find unique answers. Hence, confluence implies consistency. Hence, we also obtain type safety. * Dropping the Coverage Condition There are numerous examples which violate this condition. Naively dropping this condition potentially threatens decidable type inference (due to non-termination) and type safety (due to non-confluence). * Weak (aka refined) Coverage Condition Guarantees local confluence (critical pairs are joinable). Assuming that instances are terminating we obtain confluence (by Newman's Lemma). The bad news is that typical examples which violate the coverage but satisfy the weak coverage condition are non-terminating. Consider the classic example class F a b | a -> b instance F a b => F [a] [b] where for constraint F [a] a the type inferencer will not terminate The good news is that in "On Termination, Confluence and Consistent CHR-based Type Inference", ICLP'14, we show that (under some modest extra conditions) for terminating type inference goals we find unique answers. In essence, we're happy to achieve local confluence under the assumption that we have local termination. * XUndecidableInstances Enforces the weak coverage condition but gives up on (global) termination. Assuming that the GHC type inference terminates nothing bad will happen though (cause we find unique answers, see above) * DysfunctionalDependencies I can only guess what this means as I couldn't find any concrete definition. My impression is to drop the weak coverage condition? Bad idea! We no longer have local confluence. We might be lucky enough that GHC always applies type inference rules (FD improvement, instances) in a fixed order and thus 'unique' answers are guarantees. Sounds rather brittle to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 10:04:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 10:04:45 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages In-Reply-To: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> References: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> Message-ID: <068.c012998823479efe6ea92cedda89d14c@haskell.org> #8414: ghc-pkg prevents dynamic library only packages -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: Component: ghc-pkg | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Other Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by ezyang): Note that you can override GHC's file checks using {{{-force-files}}}. But perhaps that is too heavy of a hammer here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 10:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 10:23:47 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.33f9fe1e79028d35db4db79805447a1c@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): Martin, thanks. Yes, as comment:14 specifies (fairly precisely I thought), `DysFunctionalDependencies` means relaxing the coverage condition altogether. Let me stress once more that, apparently contrary to your second bullet, dropping coverage does not threaten type soundness. I'm not quite sure what you mean by "type safety". I did actually go back to our JFP paper "Understanding functional dependencies using constraint handling rules" to see if I could find a concrete example of the problems that might arise, but all I could find I was the unsupported claim that "all is lost" if we don't have confluence. I ''believe'' (but I have no example that demonstrates) that dropping the Coverage Condition might mean that a small change in the program makes a large difference in whether the type inference algorithm succeeds. But it would be good to have some concrete cases. One way to gather some might be to allow it, and see whether our users start complaining about unpredicatable inference. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 11:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 11:15:49 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.241dbad76e0375a01a0cd416c7ab2ac6@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > > the compiler is still not built with -O2 > True, but one step at a time. (I?ll time this change later, probably over lunch.) {{{ 4311.12user 223.56system 42:58.26elapsed 175%CPU (0avgtext+0avgdata 1557124maxresident)k 256824inputs+18215896outputs (472major+251942192minor)pagefaults 0swaps }}} Another +5 minutes, so I won?t argue for changing that at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 11:33:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 11:33:04 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.366f25f9f3905a3a31f850eeefa2a215@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by blitzcode): I'm afraid, I can't. I was able to build HEAD, but I don't know how to setup a package db containing mtl for it so I can compile the snippet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 12:03:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 12:03:13 -0000 Subject: [GHC] #9092: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> References: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> Message-ID: <061.83971c1f82be1f7d55eb5140b2286f5b@haskell.org> #9092: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: alex404 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: panic impossible Differential Revisions: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by alex404): This was indeed fixed in 7.8.3. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 12:03:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 12:03:41 -0000 Subject: [GHC] #9092: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> References: <046.b9f7cb051e72bab7727c2bd0d31fa554@haskell.org> Message-ID: <061.0d1aa6262ef1d1356678eebccf096735@haskell.org> #9092: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: alex404 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: panic impossible Differential Revisions: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by alex404): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 12:07:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 12:07:27 -0000 Subject: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative In-Reply-To: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> References: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> Message-ID: <059.959de8a588aa7c0c4742ee98cabf86b9@haskell.org> #5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: bgamari => ezyang Comment: OK, I can confirm that there is something fishy going on here. Here is the matrix of behaviors that ghc-pkg implements right now: * If P is in the user and global, {{{unregister --user}}} removes user, {{{unregister --global}}} removes **USER**, {{{unregister}}} removes user * If P is in the user but not global, {{{unregister --user}}} removes user, {{{unregister --global}}} removes **USER**, {{{unregister}}} removes user * If P is in the global but not user, {{{unregister --user}}} removes **GLOBAL**, {{{unregister --global}}} removes global, {{{unregister}}} removes global This seems clearly wrong. The bug seems to me that ghc-pkg calculates the database to modify fine, but then ignores it in {{{modifyPackage}}}, always using the full database stack rather than the database it calculated to use. My suggested fix is to switch unregister to use the flag package stack, since it is implicitly a read, and then a delete. But I don't know if there is any existing tooling that would be broken by this fix. I have a patch and test-cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 12:53:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 12:53:55 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.25f783846a59aed53452471d42f6b216@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:21 nomeata]: > > validate takes a minute longer > > Out of more than half an hour. It?s not like validate is fast enough so that people can actually sit and watch it. And no matter whether its 36 or 37 minutes, I guess most will stop running validate themselves and rather leave that to Phabricator or other CI stuff, precisely because validate takes so long and its convenient to let someone else do it for you. But then where do you stop? By your arguments we should be making validate run the full testsuite, which takes 3 hours or so (IIRC). When we first made validate it took 15 mins, now it takes more than double that, and we arrived here not by huge leaps, but by adding one minute at a time. So every time I see this happening, I like to question (vigorously!) whether that extra minute is paying for itself. In this case I'm not at all convinced. The point of validate is to catch bugs that will block other developers if they get committed: build breakage or serious bugs, whereas everything else we catch with the nightly builds, If there's a feeling that we should change this, then let's take that discussion to the mailing list. It's not at all clear-cut (which is why we're having this discussion!). What I'd like to see instead is one of the following: * Skip the test unless the libraries were built with -O2 * Skip the test *if* the libraries were built with -O2 * Have different results according to the optimisation levels All of which fix the perceived problem without introducing the regression in validate time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 12:58:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 12:58:36 -0000 Subject: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative In-Reply-To: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> References: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> Message-ID: <059.deb1e89bde4398a711afc9e149a2314e@haskell.org> #5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: | Keywords: Differential Revisions: Phab:D84 | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D84 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:02:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:02:23 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.684d75ee4d74e814a98b2be6dc06ac58@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by sulzmann): Correct. I'm too pessimistic in my comment. For type safety (well-typed programs cannot go wrong) it suffices to have consistency. Simon, surely the Consistency Condition must hold at least, right? I agree then that the Coverage Condition (or variants) can be dropped. See Theorem 1 in the above mentioned paper. I still find it strange that you want to drop the Coverage Condition (or variants of it). This clearly leads to non-confluence, hence, unpredictable type inference. Consider class F a b | a -> b where f :: a -> b -> a instance F b a => F [a] [b] -- Order of 'a' and 'b' swapped! -- Hence, (weak) coverage is violated. g as bs c = (f as bs, f as c) The above gives (roughly) rise to the constraints F [a] [b], F[a] c Depending on the order type inference rules are applied, the following two final constraints may arise (1) c = [b], F b a (2) c = [b'], F b a, F b' a Say we use (1) for some type annotation but the type checker only comes up with (2). Urgh! To conclude: - For type safety we require at least consistency - For predictable type inference we require (local) termination and (weak) coverage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:09:13 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.5c73009790ecfb9afb9af5d472a14ee1@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): I've got a single question related to this topic - lets assume I've got a simple code: {{{#!haskell {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE DysfunctionalDependencies #-} class CTest a b | a -> b where ctest :: a -> b data X = X instance Monad m => CTest X (m Int) where ctest _ = return 5 main = do let f = ctest X -- ... some code here print "end" }}} Is it possible in such example, that anything would break using the `-XDysfunctionalDependencies` (assuming, that all instances mention concrete types for `a`, like the one on the example, which mentions `X` in place of `a`)? This is the exact case we need to use it right now (of course very simplified). For now it works very well even for large examples. When such code "could" break and give us unpredictable results? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:13:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:13:24 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.083eb11c9a839ce40cca78760c2051ec@haskell.org> #703: all binaries built by ghc have executable stacks -------------------------------------+------------------------------------- Reporter: duncan | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 (NCG) | Keywords: Resolution: fixed | Operating System: Linux Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: N/A Unknown/Multiple | Blocking: Difficulty: Moderate | (less than a day) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Jens' builds of ghc-7.8 in copr (http://copr.fedoraproject.org/coprs/petersen/ghc-7.8) correctly do not have the executable bit. I'm going to close this bug unless someone actually reports that their builds have the executable bit set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:15:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:15:37 -0000 Subject: [GHC] #7831: Bad fragmentation when allocating many large objects In-Reply-To: <045.1f9dc6d6e509a58f42438bf0fc937d10@haskell.org> References: <045.1f9dc6d6e509a58f42438bf0fc937d10@haskell.org> Message-ID: <060.9aa08070420c357f48220d3b26a7fbf2@haskell.org> #7831: Bad fragmentation when allocating many large objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: ? Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low * milestone: 7.10.1 => ? Comment: I don't think we are planning on fixing this any time in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:23:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:23:45 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.6f7699710a5516befe13be7393d5b252@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I tried to bring it up on the mailing list, but nobody cared... > What I'd like to see instead is one of the following: > > * Skip the test unless the libraries were built with -O2 > * Skip the test *if* the libraries were built with -O2 > * Have different results according to the optimisation levels > > All of which fix the perceived problem without introducing the regression in validate time. While the third option is the most complete, I don?t think it is maintainable. Given the aim of validate is to prevent breakage, and performance regressions are not breakage, I think it is ok to skip the tests there (even makes it faster!), and run the tests only when we are doing a release build. So how about this: * The expected numbers are adjusted to reflect the release settings. * `validate` in modes fast and normal pass `SKIP_PERF_TESTS` to the test suite * `validate` in slow mode uses the release settings (`-O2` to libraries and stage2), and does not `SKIP_PERF_TESTS` * Optionally: The test suite, when invoked manually, ignores performance tests if the flags are not as expected? Note that the test suite already skips compiler performance tests if `-DDEBUG` is set, so this has precedent. ? Is that possible in a reliable and not-too-complicate way, and without duplicating the ?expected flags?? Maybe a warning ?You have a custom `mk/build.mk`; failures in performance tests might be irrelevant.? would be enough -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:35:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:35:48 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.056dfaf02c7e55da732cee248ec81acb@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by maeder): under solaris I had to "LC_ALL=C" in order to get rid of this stupid version check. It should be fixed in compiler/main/SysTools.lhs. Maybe calling "gcc --version" or "gcc -dumpversion" makes it easier. Otherwise "LC_ALL=C gcc -v" should be called. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:37:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:37:00 -0000 Subject: [GHC] #8874: Warning: Couldn't figure out linker information! In-Reply-To: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> References: <046.d67a2973b6290e10568e89b029230c9a@haskell.org> Message-ID: <061.a32ee95fbdb9176702788088a677d09c@haskell.org> #8874: Warning: Couldn't figure out linker information! -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: duplicate | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8825 | -------------------------------------+------------------------------------- Changes (by maeder): * status: new => closed * resolution: => duplicate Comment: indeed duplicate of #8825 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:57:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:57:06 -0000 Subject: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative In-Reply-To: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> References: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> Message-ID: <059.7798298ceb1d7bff2bb9c3791c56d1a2@haskell.org> #5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: | Keywords: Differential Revisions: Phab:D84 | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"d7c807f7975c13444e1ce79e4c36dd802321cf40/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d7c807f7975c13444e1ce79e4c36dd802321cf40" [ghc-pkg] Fix #5442 by using the flag db stack to modify packages. Summary: Previously, the full database stack was used for ghc-pkg to modify packages, which meant that commands like 'ghc-pkg unregister --user' worked the same as 'ghc-pkg unregister'. Since package modification is a "read and write" operation, we should use the flag db stack (which is currently used for reads) to determine which database to update. There is also a new flag --user-package-db, which lets you explicitly set the user database (as seen by --user). This was mostly added to aid in testing, but could be useful for end users as well. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D84 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 13:58:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 13:58:17 -0000 Subject: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative In-Reply-To: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> References: <044.72a3710c92a21702e9ab29aa4c540ee5@haskell.org> Message-ID: <059.c1d706f949c8e2d340129bdef14c7fd7@haskell.org> #5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: fixed | Keywords: Differential Revisions: Phab:D84 | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 14:36:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 14:36:06 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.07c48e1760c93b4f2bfce2a686f7db66@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: fixed | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 14:47:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 14:47:20 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.50923725f5de1ba0d04ec5f6521cbdc1@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Differential Revisions: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by artella.coding): "namely the tension between sharing computation and saving space." - but in this case there doesn't seem to be any sharing of computation (unless I am mistaken). The key things I noted were : a)The result of `takeWhile (< 10000000) longList` seems to be persisting, and not `longList` itself b)The result of `takeWhile (< 10000000) longList` is only used once in subsequent invocations of `main`, and therefore it is not shared '''between''' computations My way that I arrived at my deductions were as follows : a)Firstly we note that it is the list resulting from `takeWhile (< 10000000) longList` which seems to be persisting, and not `longList` itself. This is supported by the fact that if you replace it with `takeWhile (< 10) longList` the program no longer blows up. If it was `longList` that was persisting, then the program would blow up in both cases. b)So given that `takeWhile (< 10000000) longList` persists (and not `longList`), the question then remains as to whether `takeWhile (< 10000000) longList` is '''shared between subsequent''' computations. In order to test this I put a `trace` command to see whether `takeWhile (< 10000000) longList` is invoked twice when `main` is run twice from within ghci. That is if we modify the program in comment 10 (https://ghc.haskell.org/trac/ghc/ticket/9332#comment:10) to the following : {{{ --Sort.hs module Sort (result) where import Data.List import Debug.Trace longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ (trace "test") takeWhile (< 10) longList }}} and : {{{ --Main.hs module Main (main) where import Sort (result) main = do print $ result }}} Then we find that upon running `main` twice in ghci we get : {{{ > main test 45 > main 45 }}} So we note that `"test"` is only printed out once, which indicates that once `result` is calculated its value is cached, which means that the list arising from `takeWhile (< 10) longList` is only used once, and hence is not shared between subsequent computations. Therefore if the result of `takeWhile (< 10) longList` is not shared between subsequent computations, why does it persist in memory? Thanks Replying to [comment:11 simonpj]: > There is a difficult tension here, described in Chapter 23 of my [http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj- book-1987/index.htm 1987 book], namely the tension between sharing computation and saving space. I do not know of any comprehensive answer. > > The problem tends to bite less when (as is commonly the case) numbers like `1000000` don't appear in your program but rather are computed from the input or the command line flags. But it's still definitely a problem (e.g. with `[1..]`.) > > A possible solution might be to revert any CAFs that are retaining a great deal of space, by turning them back into their un-computed form. (Of course, their uncomputed form might retain a great deal of space too!) > > Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 14:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 14:56:54 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.c3f97dfbc0c29401503a35c80b7a96f8@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by sulzmann): You should be fine in the situation you describe above. The type inferencer is faced with a single constraint CText X t for some t which is then reduced to t = m Int, Monad m In my example I assume two occurrences of method f which result in F [a] [b], F[a] c This leads then to a conflict between the FD and the instance rule. Hence, we find two distinct final constraint stores (1) and (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:08:59 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.ccb7d17fd2a5297297e56b7c2022fa38@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): @sulzmann - great, so `-XDysfunctionalDependencies` are safe for our purposes - we never define instances described by your example :) Its very good to hear that, because we've got such instance in core system of our product, which works great now and we do not imagine how could we handle it other way around :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:17:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:17:19 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.2d82951be56dcf63e857bb0536fe136a@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): OK, Martin, that's a good example (in comment:26). Let's see a bit more detail. We start with {{{ F [a] [b], F [a] c }}} Now there are two sorts of "improvement" rules which might fire: A. '''Between two constraints'''. Since we have `F [a] [b]` and `F [a] c`, we may derive `[b] ~ c`. After all the class fundep for `F` claims that `a -> b`. B. '''Between a constraint and an instance declaration'''. Here we have * `instance forall p q. F q p => F [p] [q]` (I have alpha-renamed.) * `F [a] c` Since the `[a]` matches the `[p]` we may conclude that `c ~ [q']`, where `q'` is a fresh unification variable, reflecting the fact that the instance declaration says the second parameter must be a list but doesn't tell you what the element type is. So Martin's point is that there are two possible solution paths: {{{ F [a] [b], F [a] c ===> Use (A) to combine the two F [a] [b], F [a] c, c ~ [b] ===> Use the instance declaration to simplify F b a, c ~ [b] }}} Here is the other path: {{{ F [a] [b], F [a] c ===> use the instance declaration F b a, F [a] c ===> use (B) to combine the second constraint with the instance F b a, F [a] c, c ~ [q'] ===> use the instance declaration again F b a, F q' a, c ~ [q'] (stuck) }}} This is helpful: it's a concrete example that demonstrates how minor variations in the way the inference engine works may lead to unpredictable failures in type inference. One possible reaction is that if you are going to lift the Coverage Condition, then (A) yields too many equalities, and you shouldn't use it. But (B) is still useful, and is actually what is wanted here. So maybe we want {{{ class C a b | a ~> b }}} notice `a ~> b` rather than `a -> b`, meaning "`a` specifies the ''shape'' of `b`", which would make use improvement rule (B) but not (A) for this fundep. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:22:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:22:22 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.990a382f8f8902c79ad4c6973a37d344@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Comment (by simonpj): What happens if you try {{{ foreign import ccall unsafe "integer_gmp_mpn_tdiv_q" c_mpn_tdiv_q :: MutableByteArray# s -> ByteArray# -> GmpSize# -> ByteArray# -> GmpSize# -> State# s -> State# s }}} with `-XUnliftedFFITypes`? Answer {{{ Unacceptable argument type in foreign declaration: State# s }}} But why is `State# s` unacceptable? I can think of no good reason. So I think that it might be as simple as * Adding `State#` to the list of acceptable FFI types (with `-XUnliftedFFITypes`. * Making sure that, since it's a zero-width value, we don't actually pass it to the C function. The latter step is in the code generator itself; these zero-width values ''do'' (and must) survive into `Cmm`. If you'd like to tackle this I'm sure Simon and I would help with any bits you don't grok. I think this would be MUCH simpler than trying to allow types like `IO Int#`, which has global implications that I don't know how to deal with. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:27:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:27:18 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.453172984b4261c97896fe26f82a8a1d@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by GregWeber): * owner: => GregWeber -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:28:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:28:22 -0000 Subject: [GHC] #9126: -ddump-to-file in TcRnMonad.lhs In-Reply-To: <048.69a311618464257df9b637c94b74c85f@haskell.org> References: <048.69a311618464257df9b637c94b74c85f@haskell.org> Message-ID: <063.0ebd32ca04a5528ddc849f5e60ddc678@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Description changed by GregWeber: Old description: > As part of #8624, the first thing we realized is -ddump-to-file wasn't > being respected. This is against HEAD, but I would really like to merge > it to 7.8.3 if that is ok. > > I tested this with -ddump-tc and -ddump-splices. New description: As part of #8624, the first thing we realized is -ddump-to-file wasn't being respected. The patch is against HEAD. I tested this with -ddump-tc and -ddump-splices. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 15:47:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 15:47:20 -0000 Subject: [GHC] #9265: Extend PackageId to include version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.030f5a442d41f3151b1673ca73ffe070@haskell.org> #9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Package system | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edward Z. Yang ): In [changeset:"4bebab25e4c9a3bfccc491d4dd13c685629cd1de/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bebab25e4c9a3bfccc491d4dd13c685629cd1de" Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. Summary: Previously, both Cabal and GHC defined the type PackageId, and we expected them to be roughly equivalent (but represented differently). This refactoring separates these two notions. A package ID is a user-visible identifier; it's the thing you write in a Cabal file, e.g. containers-0.9. The components of this ID are semantically meaningful, and decompose into a package name and a package vrsion. A package key is an opaque identifier used by GHC to generate linking symbols. Presently, it just consists of a package name and a package version, but pursuant to #9265 we are planning to extend it to record other information. Within a single executable, it uniquely identifies a package. It is *not* an InstalledPackageId, as the choice of a package key affects the ABI of a package (whereas an InstalledPackageId is computed after compilation.) Cabal computes a package key for the package and passes it to GHC using -package-name (now *extremely* misnamed). As an added bonus, we don't have to worry about shadowing anymore. As a follow on, we should introduce -current-package-key having the same role as -package-name, and deprecate the old flag. This commit is just renaming. The haddock submodule needed to be updated. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D79 Conflicts: compiler/main/HscTypes.lhs compiler/main/Packages.lhs utils/haddock }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 16:04:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 16:04:49 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.016d826f06f3ec4b162860ce3bdbc58f@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by diatchki): This program has the exact same problem as the one in the ticket above: it violates the functional dependency. Having a "functional dependency" simply means that you are telling GHC that you want to work with a "functional relation (in the specified parameters)", and it should give you an error if you made a mistake. Here is how you can rewrite your program without `Dysfunctional Dependencies`: {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} data X = X class C a b where ctest :: a -> b class D a f b | a -> b where dtest :: a -> f b instance Monad m => D X m Int where dtest _ = return 5 instance (Monad m) => C X (m Int) where ctest = dtest main = print (ctest X :: [Int]) -- [5] }}} Replying to [comment:19 danilo2]: > @diatchki please do not base your opinion on the examples above - they are a little old and of course, they do not obey some basic principles. > The idea with `-XDysfunctionalDependencies` is just to lift both the Paterson Conditions and the Coverage Condition - something `-XUndecidableInstances` claims to do (according to documentation), but does not (as simonpj noticed above). When using this extension you can just give some interesting hints to typechecker and compile programs like the one I've posted on https://phabricator.haskell.org/D69 : > > {{{#!haskell > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE DysfunctionalDependencies #-} > > class CTest a b | a -> b where > ctest :: a -> b > > data X = X > > instance Monad m => CTest X (m Int) where > > ctest _ = return 5 > > main = print (ctest X :: [Int]) -- [5] > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 16:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 16:11:49 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.cd46ae20ddbe86ed723272f63497f1f4@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 nomeata]: > > That looks wonderful. Is it certain to be changed to a foldl' in cases where it doesn't fuse? > > Hopefully not. `foldl'` would force the accumulator, which we do *not* want here (otherwise the `undefined` would be forced, or `last [undefined, 1]` would not work). Yes, you're right. I got mixed up a bit. > I didn?t do further testing with that idea, it just crossed my mind. It maybe the that this implementation is only good when fusing works ? would you mind trying to find out? I don't have anything beyond 7.8.3, and on 7.8.3 your code doesn't fuse. Could you maybe try it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 16:15:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 16:15:11 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.9a07d4e3a2cc23849188449a43916703@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Comment (by hvr): fwiw, if you use `prim`-FFI imports instead of `ccall` , `... -> State# s -> State# s` as well as `... -> State# s -> (# s, Word# #)` already works. Is this maybe just a matter of replicating what's already done for `prim`-style FFI/Cmm calls? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 16:25:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 16:25:49 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.7d87b94a692b6d71de02d682f969a062@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by diatchki): comment:14 specifies what GHC is NOT going to do, but it does not specify what it will do! As a programmer, when I see a class-declaration: {{{ class C a b | a -> b }}} I think: ''Aha, there is a functional relation between the parameters of this class. This means that whenever the first parameters of instances are the same, so will be the second ones''. I don't know what this declaration means in the context of `Dysfunctional Dependencies`. I am also unclear about why `DysfunctionalDependencies` removes some of the consistency checks but not ``all``? I believe that due to the current GHC implementation, "nothing will go wrong" even if we allowed instances such as `C Int Char` and `C Int Bool`, or am I missing something? All of this will change, however, if we were to complete the implementation of FDs and added support for using the FDs on given constraints: then type-safety actually depends on the consistency of the instances, and we better not have any `Dysfunctoinal Dependencies` around. Replying to [comment:25 simonpj]: > Martin, thanks. Yes, as comment:14 specifies (fairly precisely I thought), `DysFunctionalDependencies` means relaxing the coverage condition altogether. > > Let me stress once more that, apparently contrary to your second bullet, dropping coverage does not threaten type soundness. I'm not quite sure what you mean by "type safety". I did actually go back to our JFP paper "Understanding functional dependencies using constraint handling rules" to see if I could find a concrete example of the problems that might arise, but all I could find I was the unsupported claim that "all is lost" if we don't have confluence. > > I ''believe'' (but I have no example that demonstrates) that dropping the Coverage Condition might mean that a small change in the program makes a large difference in whether the type inference algorithm succeeds. But it would be good to have some concrete cases. One way to gather some might be to allow it, and see whether our users start complaining about unpredicatable inference. > > Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 16:37:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 16:37:32 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.c264b50c10e21916bddffa131ddad5c0@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Still not a full evaluation, but some more factoids: With {{{ myLast2 = foldl (\_ x -> x) undefined }}} I get {{{ myLast2 :: forall a. [a] -> a myLast2 = \ (@ a) -> foldl (myLast1) (undefined) }}} while when used (in the same model, non-fusing), this gets turned into the nice {{{ Rec { main_go :: [Int] -> Int -> Int main_go = \ (ds :: [Int]) (eta :: Int) -> case ds of _ { [] -> eta; : y ys -> main_go ys y } end Rec } }}} Writing {{{ myLast2 = inline foldl (\_ x -> x) undefined }}} also gives {{{ Rec { myLast1 :: forall a. [a] -> a -> a myLast1 = \ (@ a) (ds :: [a]) (eta :: a) -> case ds of _ { [] -> eta; : y ys -> myLast1 ys y } end Rec } myLast2 :: forall a. [a] -> a myLast2 = \ (@ a) (xs :: [a]) -> myLast1 xs (undefined) }}} So it looks good even when not fused. (Measurements are yet pending.) for the exported module, but when used, it produce -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 17:01:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 17:01:33 -0000 Subject: [GHC] #9150: libraries/time: parseTime barfs on leading space in format string In-Reply-To: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> References: <042.1b275f11b4cf8dd08f74601d64b4d5b4@haskell.org> Message-ID: <057.c045ce98e1961be8b65552a2d17e6bd9@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string -------------------------------------+------------------------------------- Reporter: mjo | Owner: Ashley Yakeley Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.2 (other) | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by mjo): Replying to [comment:2 Ashley Yakeley]: > Another alternative would be to drop skipping of leading and trailing spaces. This would make the behaviour of the parsing functions more predictable. However, the current behaviour has been there since time-1.1 from 2007, so programs that depend on it will fail with stricter functions. I assumed this was a bug because the behaviour changed between time-1.4.0.1 and time-1.4.2. I've narrowed down the change to time-1.4.0.1 -> time-1.4.0.2. Maybe I'm misunderstanding what you wrote, but your examples at least seem to parse fine with the older library. {{{ $ ghc-pkg list | grep time old-time-1.1.0.1 time-1.4.0.1 $ ghci ... > parseTime defaultTimeLocale "%Q " " " :: Maybe LocalTime Just 1970-01-01 00:00:00 > parseTime defaultTimeLocale "%k" " 8" :: Maybe LocalTime Just 1970-01-01 08:00:00 }}} The two examples in the description also both worked in earlier versions: {{{ > parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime Just 1970-01-01 00:15:00 UTC > parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime Just 1970-01-01 00:15:00 UTC }}} Maybe there was a bug in time <= 1.4.0.1 that prevented the spaces from being skipped? For what it's worth, my use case is in pickling/unpickling XML. The package is now public at http://hackage.haskell.org/package/htsn-import. I have a test case that basically says, if we unpickle some XML and then repickle it, we should get what we started with. For that to work, the leading/trailing space needs to be preserved (I don't control the XML so I'm stuck with the spaces). I have a test case ensuring that, and with time-1.4.0.1 it passes. Once I upgraded the time library along with ghc, I noticed the failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 17:29:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 17:29:54 -0000 Subject: [GHC] #9343: foldl' is not a good consumer Message-ID: <045.8d25a445435dfd5ef8b3e22e67a0d62a@haskell.org> #9343: foldl' is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Some fancy footwork went into making length a good consumer. Since `length = foldl' (\n _ -> n + 1) 0`, I was wondering if a trick similar to the one used for length might work for more general strict left folds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 17:43:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 17:43:03 -0000 Subject: [GHC] #8364: equip GHC with an accurate internal model of floating point In-Reply-To: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> References: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> Message-ID: <060.526b8d3216d664d3e55a2dfdc16b6812@haskell.org> #8364: equip GHC with an accurate internal model of floating point -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Project | (more than a week) | Blocked By: 9276 | Related Tickets: #9276 | -------------------------------------+------------------------------------- Changes (by carter): * related: => #9276 * blockedby: => 9276 Comment: probably should first finish conducting the ghc ieee audit before this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 18:20:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 18:20:51 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.adfe5510c657c6c65ed59ef6408c290b@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by diatchki): Replying to [comment:3 simonpj]: > * The instance chains described in the instance-chain paper are much more elaborate than your proposal here; in particular they involve backtracking search and a "fails" possibility. I imagine that is a deliberate narrowing of the specification on your part. Yeah, I thought that we should start simple :) I'll try to meet with Mark to understand better how the full system should work. For now, I just wrote up the part that I think fits easily with GHC. > * The behaviour you specify for instance chains is, I think, precisely what GHC does for overlappping instances ''when they are all declared in the same module''. See the bullets at the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5 in the user manual]. I grant that putting all the overlapping equations together in one place is clearer, just as with closed type families. But you have the behaviour you want right now, I think. Interestingly, even in my simple version, instance chains are a bit more expressive, because of the explicit ordering of instances. So we can write things like this: {{{ instance C Int a where ... else C a Int where ... }}} I am not sure how common cases like these are, but it is worth noting. > * I think you are arguing that we should ''replace'' overlapping instances with instance chains. That would render illegal any program that uses overlaping instnaces spread across modules. I suspect that would make many people cry, so we'd end up with both. Ah, not yet! I think the two can coexist for a while. Once we have a working version of instance chains we can see if existing overlapping instances code can be replaced, and if not, why not. > If I have this right, its just a question of whether to support a chained syntax. For the simple implementation, I think I'll start by adding the syntax (in all passes of the front-end), and then modifying `InstEnv` to keep track of instance-chains rather than individual instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 18:26:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 18:26:03 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.3048b26cf117901f6065c3bb251e8701@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by sulzmann): Here's a brief summary of my current understanding: At all times we demand (the) Consistency (Condition). For instance, the following example violates the Consistency Condition. class C a b | a -> b instance C Int Bool instance C Int Char The Consistency Condition is the minimal requirement to guarantee type safety. (1) The Coverage Condition guarantees termination and confluence for all programs. Recall confluence means that we find unique answers. (2) The Weak Coverage Condition guarantees (local) confluence assuming that we can establish (local) termination. That is, if the type inferencer terminates for some constraint arising from some program text (aka goal constraint) then we know the answer is unique. (3) So what happens if we drop coverage (but of course still demand consistency)? Then we can neither guarantee termination nor confluence (which is obviously bad for predictable type inference). The example I gave still enjoys termination but in general we encounter non-confluence. danilo2 mentions some specific application scenario where for the specific constraints arising out of the program text we seem to find unique answers. I agree that the naming of GHC flags (UndecidableInstances, DysfunctionalDependencies) connected to (2) and (3) is not very helpful and rather confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 19:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 19:47:38 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.4ffa848ea14afed250a6612e12b55485@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): @diatchki - you are right - in this simple example your solution would work and will fulfill the LCC (Liberal Coverage Condition). Again - trying to simplify examples, they got oversimplified sometimes. I will try to put here another one, a little more complex: {{{#!haskell {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE DysfunctionalDependencies #-} class Property a b | a -> b where property :: a -> b data X = X data Y = Y instance Monad m => Property X Y where prperty _ = Y instance Monad m => Property Y (m Int) where property _ = return 5 main = do let f = property $ property X -- ... some code here print "end" }}} Let assume the above code is generated an **rarely** there is situation that the LCC condition is not met (as with the second instance). Property is just an associated object with current one. We want to create chains of associated objects, like `property $ property $ property Z`. To do so, we have to use functional dependencies. Additional there is no way of checking if such chain violates or not the LCC. This is the users responsibility (I can explain this further if needed). Sometimes it could happen, that LCC would be not met, as I showed above, but it still (!) tells: "Aha, there is a functional relation between the parameters of this class. This means that whenever the first parameters of instances are the same, so will be the second ones." and this is still true for `-XDysfunctionalDependencies`! The difference is, as shown by @sulzmann, that the Coverage Condition is completely lifted. The above example is still very, very simplified and does not show the complex of the problem, but as I mentioned above - we have moved succesfully our code from GHC 7.6 into GHC 7.10(head) with the extension of `-XDysfunctionalDependencies` and it just works (even with large "connection chains" (mentioned above). I think it just works in this scenario and still, the fundeps are talking to as, that whenever the first parameters are the same, so will be the second ones. One thing that is not so beautifull is the name - I do not know if `-XDysfunctionalDependencies` or `-XUndecidableInstances` are proper names for their behaviours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 20:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 20:23:02 -0000 Subject: [GHC] #9343: foldl' is not a good consumer In-Reply-To: <045.8d25a445435dfd5ef8b3e22e67a0d62a@haskell.org> References: <045.8d25a445435dfd5ef8b3e22e67a0d62a@haskell.org> Message-ID: <060.be3630d67fe77b1db9981c4e8018d6cd@haskell.org> #9343: foldl' is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: duplicate | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 20:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 20:24:01 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.115ad353e51ddf44bec05f17835752af@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by emertens): Instead of using "dysfunctional" dependencies, the above programs can be written in GHC today as shown below. This pattern actually happens in the wild regularly and takes advantage of the way GHC resolves instances. {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} class Property a b where property :: a -> b data X = X data Y = Y deriving Show instance (y ~ Y) => Property X y where property _ = Y instance (Monad m, m Int ~ y) => Property Y y where property _ = return 5 main = do print =<< property Y print (property Y :: [Int]) print (property X) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 21:29:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 21:29:29 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.a875363b9285a24b553d6690e8469637@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: T9156 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by gintas): Re-added the comment and fixed the cosmetic issues you mentioned, please take a look. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 22:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 22:00:58 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.3a43566d7780c018777d11f268f8e8d5@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Ok, let?s do this systematically. My benchmarks: One possibly fusing invocation of `last`: {{{ main = print $ Last.last $ filter odd $ [1::Int ..100000000] }}} and one non-fusing {{{ f = id {-# NOINLINE f #-} main = print $ Last.last $ f $ filter odd $ [1::Int ..100000000] }}} I am comparing the existing implementation of `last`, which is {{{ last [] = errorEmptyList "last" last (x:xs) = last' x xs where last' y [] = y last' _ (y:ys) = last' y ys }}} with the simpler {{{ last = foldl (\_ x -> x) (errorEmptyList "last") }}} Just for fun (and because GHC HEAD still compiles), here the numbers with GHC-7.6: {{{ LastTestFusing.hs <> LastTestNonFusing.hs <> NewLastTestFusing.hs <> NewLastTestNonFusing.hs <> }}} No significant difference in either of these. Now the interesting numbers are those with ghc HEAD, and for that I have to wait for the compilation to finish... So here they are: {{{ LastTestFusing.hs <> LastTestNonFusing.hs <> NewLastTestFusing.hs <> NewLastTestNonFusing.hs <> }}} We see that the new implementation performs the same in the non-fusing case, but much better in the fusing case. Why does it even allocate in the fusing case? Because it needs to box them for the recursive call: {{{ Rec { main_go :: Int# -> Int -> Int main_go = \ (x :: Int#) (eta :: Int) -> case remInt# x 2 of _ { __DEFAULT -> case x of wild { __DEFAULT -> main_go (+# wild 1) (I# wild); 100000000 -> lvl }; 0 -> case x of wild { __DEFAULT -> main_go (+# wild 1) eta; 100000000 -> eta } } end Rec } }}} Guess that?s unavoidable here. Also, to make sure that some integer unboxing doesn?t skew the comparison, here the numbers with `Integer`: {{{ <> LastTestNonFusing.hs <> NewLastTestFusing.hs <> NewLastTestNonFusing.hs <> }}} This only confirms the previous findings. TL;DR: Implementing `last` with `foldl` has no negative consequences, but works nicely when fused. I don?t expect that to happen often, but it?s still nice to have, and actually simplifies the existing library implementation. If noone complains, I?ll push this soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 22:05:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 22:05:37 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.52b018832e72eac675eb6e26061ba6b4@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: T9156 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Looks good to me. I think I?ll try to create a Pharicator code review thingy tomorrow, just to get used to the new tool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 21 22:13:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jul 2014 22:13:48 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.37b009ce45fbf80ec01013323a16197d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): @emertens: I know it really well, it would not work - look at this example: {{{#!haskell {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} class Property a b where property :: a -> b data X = X data Y = Y deriving Show data Z = Z deriving Show instance (y ~ Y) => Property X y where property _ = Y instance (z ~ Z) => Property Y z where property _ = Z tst a = property $ property a main = do print (property $ property X) }}} Error: {{{#!haskell Could not deduce (Property s0 b) arising from the ambiguity check for ?tst? from the context (Property a s, Property s b) bound by the inferred type for ?tst?: (Property a s, Property s b) => a -> b at Tmp.hs:21:1-29 The type variable ?s0? is ambiguous When checking that ?tst? has the inferred type tst :: forall b s a. (Property a s, Property s b) => a -> b Probable cause: the inferred type is ambiguous }}} It will work for simple examples but will fail for functions like `tst` - it's caused by open world assumption - you never knows if there will be another instance defined, which will be more precise than already defined (with `-XOverlappingInstances` enabled). The only way around is to use fundeps here :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 02:51:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 02:51:39 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.84ae2dc42f86e77ea072a438cb9470d2@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by rwbarton): You can write your program with `AllowAmbiguousTypes`: add `{-# LANGUAGE AllowAmbiguousTypes, ScopedTypeVariables #-}` and change `tst` to {{{ tst :: forall a s b. (Property a s, Property s b) => a -> b tst a = property (property a :: s) }}} Your program could be equally ambiguous if it used GHC 7.6-style/dys- functional dependencies. The difference is that GHC 7.6 assumes that in `Property a s`, `a` determines `s` if and only if there is a fundep `a -> s`, though neither implication is necessarily true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 05:18:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 05:18:24 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.a227baa5f2ea98d5f8c9e570b0264860@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 blitzcode]: > I'm afraid, I can't. I was able to build HEAD, but I don't know how to setup a package db containing mtl for it so I can compile the snippet. Use `cabal install -w .../ghc/inplace/bin/ghc-stage2 mtl`. The "RULE left-hand side too complicated to desugar" warning seems to no longer trigger with HEAD, at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 05:24:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 05:24:27 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion Message-ID: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- `takeWhile` doesn't do the list fusion thing. This alternative definition seems to fix that, at least to a great extent. It fused completely in a simple test, and incompletely but still usefully in a more complex one. I don't know how to write the appropriate translate/untranslate RULES for it yet. {{{ #!haskell {-# LANGUAGE ScopedTypeVariables #-} takeWhileFB :: forall a . (a -> Bool) -> [a] -> [a] takeWhileFB p xs = build tw' where tw' :: forall b . (a -> b -> b) -> b -> b tw' kons knil = foldr go knil xs where go x rest | p x = x `kons` rest | otherwise = knil }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 05:25:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 05:25:10 -0000 Subject: [GHC] #9241: Add a"same" function to Data.Eq In-Reply-To: <047.b99c525811fd7638f7969203c831dc33@haskell.org> References: <047.b99c525811fd7638f7969203c831dc33@haskell.org> Message-ID: <062.a63e63f536ec95cb302c2e77adcf178b@haskell.org> #9241: Add a"same" function to Data.Eq -------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: feature | Status: closed request | Milestone: Priority: low | Version: 7.8.2 Component: | Keywords: libraries/base | Operating System: Unknown/Multiple Resolution: duplicate | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Also see #9330 and http://www.haskell.org/pipermail/libraries/2014-July/023283.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 05:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 05:31:59 -0000 Subject: [GHC] #9327: possibly incorrect indentation or mismatched brackets In-Reply-To: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> References: <047.3df1a23a6722857b4198d25d5cda5b9c@haskell.org> Message-ID: <062.4f218a9d4a60ab6484210d59c89ebbe2@haskell.org> #9327: possibly incorrect indentation or mismatched brackets -------------------------------------+------------------------------------- Reporter: Jefffrey | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Differential Revisions: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Actually, both snippets are valid with the NondecreasingIndentation language extension, which is on by default but off when the Haskell2010 language extension is chosen?which it is in the Test-Suite stanza of Kopia.cabal. So everything is working as expected here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 05:49:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 05:49:25 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow Message-ID: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- As discussed on libraries at haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in the attached) is a one-liner and gives very good performance in general, but poor performance in certain cases that may or may not appear in real code. The other (named `initsQ` in the attached) is slightly more complex and slightly slower in general, but its performance appears to be robust. I would personally lean toward `initsQ` for `Data.List`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 06:06:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 06:06:55 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.82501dbc2b1968a5267adc83906dd7b6@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: mod73 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Curiously my ''stage1'' compiler output matches the `mod73.stderr` file! What is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:02:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:02:21 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.8c4a5ed70766879759dc4ec65137617e@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour -------------------------------------+------------------------------------- Reporter: | Owner: ulysses4ever | Status: new Type: bug | Milestone: Priority: normal | Version: Component: Build | Keywords: System | Operating System: Linux Resolution: | Type of failure: Building GHC Differential Revisions: | failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): I encountered this error also. The full build log (line breaks inserted for readability): {{{ ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist- install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/. -optP-include -optPlibraries/dph/dph-lifted-copy/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.9.20140721 -package random-1.0.1.1 -package template-haskell-2.10.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O0 -fasm -no-user-package-db -rtsopts -odir libraries/dph/dph-lifted-copy/dist-install/build -hidir libraries/dph/dph-lifted-copy/dist-install/build -stubdir libraries/dph/dph-lifted-copy/dist-install/build -optl-L'/home/rwbarton/ghc/compiler/stage2/build' -optl-L'/home/rwbarton/ghc/libraries/transformers/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/template-haskell/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/hpc/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/hoopl/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/dph/dph-prim-par/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/old-time/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/dph/dph-prim-seq/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/dph/dph-prim-interface/dist- install/build' -optl-L'/home/rwbarton/ghc/libraries/dph/dph-base/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/vector/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/primitive/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/random/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/bin-package-db/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/binary/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/Cabal/Cabal/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/process/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/pretty/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/directory/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/unix/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/time/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/old-locale/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/filepath/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/containers/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/bytestring/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/deepseq/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/array/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/base/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/integer-gmp/dist-install/build' -optl-L'/home/rwbarton/ghc/libraries/ghc-prim/dist-install/build' -optl-L'/home/rwbarton/ghc/rts/dist/build' -optl-lrt -optl-lutil -optl-ldl -optl-lpthread -optl-lgmp -optl-lm -optl-lrt -optl-ldl -fPIC -dynamic -H64m -O0 -fasm -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist- install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/. -optP-include -optPlibraries/dph/dph-lifted-copy/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.9.20140721 -package random-1.0.1.1 -package template-haskell-2.10.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O0 -fasm -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-7.9.20140721' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../transformers-0.4.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../template-haskell-2.10.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hpc-0.6.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hoopl-3.10.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../dph-prim-par-0.8.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../old-time-1.1.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../dph-prim-seq-0.8.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../dph-prim-interface-0.8.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../dph-base-0.8.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../vector-0.10.9.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../primitive-0.5.2.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../random-1.0.1.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bin-package-db-0.0.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../binary-0.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../Cabal-1.21.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../process-1.2.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../pretty-1.1.1.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../directory-1.2.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../unix-2.7.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../time-1.4.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../old-locale-1.0.0.6' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bytestring-0.10.4.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/dph/dph-lifted-copy/dist-install/build/Data/Array/Parallel.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/Closure.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/Combinators.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/PArray.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/Scalar.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/TH/Repr.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Lifted/Unboxed.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArr.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/Base.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PDataInstances.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PRepr.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PReprInstances.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/Scalar.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/ScalarInstances.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/Types.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Base.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Double.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Float.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Int.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Tuple.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Word8.dyn_o libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prim.dyn_o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries/dph/dph-lifted-copy/dist-install/build/libHSdph-lifted- copy-0.8.0.1-ghc7.9.20140721.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make[1]: *** [libraries/dph/dph-lifted-copy/dist-install/build/libHSdph- lifted-copy-0.8.0.1-ghc7.9.20140721.so] Error 1 make: *** [all] Error 2 }}} I also got a similar error involving the symbol `dphzmliftedzmvsegzm0zi8zi0zi1_DataziArrayziParallelziPreludeziDouble_productPP_closure` previously. I'm on commit 7aabfa6292c2469cf3250e006869273fb1b356ce and BuildFlavour = quick succeeds. I don't know what the net effect of the options `-O0 -Odph -O0 -O0 -Odph -O0` is but this must have something to do with optimization settings and the VECTORISE pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:13:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:13:21 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.e4ee3dff17b7c1636814a055459b08d3@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I have some idea to make the translate/untranslate dance generic (and thus reliably usable by people wanting list fusion for their own functions) but I?ll ponder it some more. Can you explain why it fails in complex cases? And how does it perform? Is a fused `takeWhile (<10) [1..10000000]` slower than a non-fused? What happens with `takeWhile (<10) (cycle [1,100])` (if `cycle` fuses at all). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:17:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:17:53 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.4e049f6bfe9d358a4d22a23e1bff8652@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Interesting. Can you elaborate (just for the record here) when `initsQ` is faster? I would find it strange to add such complexity ?just for? `inits`. Now, if we had such a `Queue` type (which looks useful in general) in base anyways, using it would be a different story... How is the performance when the existing `Seq` is used instead of `Queue`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:21:36 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.674e32f10d8bca992171935d05554336@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour -------------------------------------+------------------------------------- Reporter: | Owner: ulysses4ever | Status: new Type: bug | Milestone: Priority: normal | Version: Component: Build | Keywords: System | Operating System: Linux Resolution: | Type of failure: Building GHC Differential Revisions: | failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is unrelated to #9007. The "recompile with -fPIC" is a pretty generic error message for "something went wrong involving a dynamic library". ld is making its best guess as to the cause. Note that the undefined reference is from Data.Array.Parallel.Prelude.Bool to a symbol in the same module! Something screwy is going on with VECTORISE I think. A workaround would be to not build DPH when building with BuildFlavour = quickest, as you almost certainly don't want to build it anyways (it takes a long time). To do so uncomment the line `BUILD_DPH=NO` in `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:26:32 -0000 Subject: [GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour In-Reply-To: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> References: <051.a385fd4ebd4375cdf2c5b49651672fd6@haskell.org> Message-ID: <066.8ddb7704ca8ba5919238aecb773bf622@haskell.org> #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC in quickest flavour -------------------------------------+------------------------------------- Reporter: | Owner: ulysses4ever | Status: new Type: bug | Milestone: Priority: normal | Version: Component: Build | Keywords: System | Operating System: Linux Resolution: | Type of failure: Building GHC Differential Revisions: | failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Old description: > I followed ?First steps? section in > [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to > build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). > During the last step (make) it comes to the error: > > {{{ > /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- > install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation > R_X86_64_PC32 against undefined symbol > `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > }}} > > I tried to just the same under Lubuntu 13.04 (i386) and got just the same > type of error on relocation (now for R_386_GOTOFF symbol) in the same > module (Data.Array.Parallel). > > The only substantial change I did to the manual is setting BuildFlavour = > quickest instead of BuildFlavour = quick. And it seems '''to be the > cause'''. The error disappears when switch to quick flavour. > > Other related bug might be #9007. New description: I followed ?First steps? section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} I tried to just the same under Lubuntu 13.04 (i386) and got just the same type of error on relocation (now for R_386_GOTOFF symbol) in the same module (Data.Array.Parallel). The only substantial change I did to the manual is setting BuildFlavour = quickest instead of BuildFlavour = quick. And it seems '''to be the cause'''. The error disappears when switch to quick flavour. -- Comment (by ulysses4ever): Ok, remove link to #9007 and thank's for the workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:29:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:29:49 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.2eade5fe9cb281c313285cb9ff6ea9e5@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by dfeuer): I wouldn't call it "failing" so much as "incomplete success". I haven't investigated in detail, and may not be good enough with Core to figure it out anyway. The simple example {{{ #!haskell print $ length $ takeWhileFB (<10000000) [1..20000000] }}} allocates virtually nothing. The more complex example {{{ #!haskell print $ length $ filter (\x->x `rem` 3 == 0) $ takeWhileFB (<10000000) $ filter even [1..20000000] }}} allocates a substantial amount, but only something like a third of what `Prelude.takeWhile` does. I haven't attempted any benchmarking, and I'm too tired right now to look into those test cases. As for speed, if I'm not very much mistaken it takes a lot of slowness and/or a good number of mispredicted branches to make up for the cache effects that excessive allocation will have when combined with non-trivial code, so I believe that should probably be a secondary concern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:47:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:47:26 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.489a441563d94d94fc80b6e3a70c6f1e@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > As for speed, if I'm not very much mistaken it takes a lot of slowness and/or a good number of mispredicted branches to make up for the cache effects that excessive allocation will have when combined with non-trivial code, so I believe that should probably be a secondary concern. True, and I?m not worried about that; I?m worried about the short- circuting of `takeWhile`: Does it properly stop the producer from calculating the rest of the list or not. From looking at the code I believe it does, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:53:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:53:33 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.c4244e1fa1d3bf2e0fd6160c6ad13e32@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: mod73 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by jrp): mod73 works again for me against the current head. Either someone fixed the issue my build system had some cruft from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 07:54:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 07:54:18 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.e1cd8a9837e0228dfb9ad26c45fe4162@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 nomeata]: > Interesting. Can you elaborate (just for the record here) when `initsQ` is faster? > > I would find it strange to add such complexity ?just for? `inits`. Now, if we had such a `Queue` type (which looks useful in general) in base anyways, using it would be a different story... > > How is the performance when the existing `Seq` is used instead of `Queue`? I'm attaching the Criterion comparison of `initsR`, `initsQ`, and a new `initsS` that uses `Data.Sequence`. On most tests, `initsS` is much slower than `initsQ`, reflecting the fact that sequences are much heavier data structures than these snoc-builder almost-queues. `initsQ` is faster when the heads (or more generally the first few elements) of several of the elements of the result list are inspected by traversing the result list. If you just calculate `head $ initsR [1..n] !! n`, then the time required to reverse the final list can be amortized over the steps in `!!n`. But if you were to calculate, for some inexplicable reason, `sum $ map head $ initsR [1..n]`, you only have `n` steps over which to amortize `n^2` work. The vague notion I've had in the back of my mind for a vaguely realistic example is some sort of breadth-first traversal of `inits [1..n]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 08:04:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 08:04:21 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.89b94759e4d153d499bc3089eeb15dc4@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: mod73 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message contains a list of suggested alternatives for an out of scope identifier. GHC makes no attempt to order this list in a canonical way, so it's not too surprising if the output wobble. Perhaps the test should do `wc` or something, or do its own sort on the output, to normalise? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 08:07:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 08:07:46 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.2194267f44bf5f20ebdcef47f8219777@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR: Seeing that the rear list of `Queue` is only consed and reversed, I tried to change it to a difference list (`[a] -> [a]`). The difference in performance is small and mixed, sometimes slightly better, sometimes slightly worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 08:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 08:29:26 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.9a20b36964c03cb74b51f9ca8ec074f8@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D82 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8647 | -------------------------------------+------------------------------------- Comment (by simonmar): `foreign import prim` has a different calling convention from `foreign import ccall` (obviously) and they look different at the `Cmm` level. The code generation for these two is quite different - the former is a `StgPrimCallOp` while the latter is a `StgFCallOp`. But I think all the machinery to do this already exists, as Simon said. When we foreign-import something with an IO type there's a wrapper around the primitive foreign call to add the IO, but the primitive call itself will have a type of the form `State# s -> (# State# s, a #)`, so we can already codegen these properly. All we need to do is make sure that there is no wrapper, which might already happen automatically if the typechecker is changed to allow `State#` arguments and `State#` or `(# State# s, a #)` results with `UnliftedFFITypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 08:46:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 08:46:59 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.3b28884212242227a948e1c7aa09c009@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: I wanted to push this as a phabricator review, but `arc` is currently broken for me. Hence I?ll parked it at `wip/T9339`. Marking as ?patch? so that this is not forgotten. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 08:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 08:57:10 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.381d61e7fd1afd5ce1a9d6a219956c20@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > I have some idea to make the translate/untranslate dance generic (and thus reliably usable by people wanting list fusion for their own functions) but I?ll ponder it some more. I have pondered them some more, but they didn?t work out so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:00:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:00:10 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.acd7d60152750a611cddf4b383eea204@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, by all means. Honestly, I am not (yet) convinced that benefit is worth the extra complexity. Do try to share code with the type-family apartness stuff; the paper on closed type families would be a good reference. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:17:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:17:47 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.04610a812937652efe3389541e43793c@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: D86 | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => D86 Comment: Code for review at https://phabricator.haskell.org/D86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:18:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:18:01 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.89aa280d19dd944cb6cdb2a479e44847@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D86 | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: D86 => Phab:D86 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:21:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:21:04 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.06119a56c06ae49f100cbd6710a1b353@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D86 | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"b709f0a047dc036de15dc43d3b0ab88d3e32c5e6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b709f0a047dc036de15dc43d3b0ab88d3e32c5e6" Make last a good consumer Summary: Make last a good consumer simply by implementing it as foldl. This fixes Trac: #9339. Thanks to David Feuer for bringing it up. Test Plan: perf/should_run/T9339 + general validation Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D86 Trac Issues: #9339 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:23:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:23:20 -0000 Subject: [GHC] #9339: last is not a good consumer In-Reply-To: <045.684d85de4a358347b6875763cb59223d@haskell.org> References: <045.684d85de4a358347b6875763cb59223d@haskell.org> Message-ID: <060.10dd2c0ffc41a985a7f1308d1f5d5ba6@haskell.org> #9339: last is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Operating System: Unknown/Multiple Differential Revisions: Phab:D86 | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:51:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:51:32 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.709653e2b89c1215c537859d0a1e9686@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.8.3 Priority: normal | Keywords: Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Resolution: | Test Case: Differential Revisions: | Blocking: Architecture: | Unknown/Multiple | Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by hvr): I'd like to push this to base, whom shall I declare as being the author? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 09:53:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 09:53:00 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.7340dda5123d0fe77f7fe66532b01d39@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: feature | Milestone: 7.10.1 request | Version: 7.8.3 Priority: normal | Keywords: Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Resolution: | Test Case: Differential Revisions: | Blocking: Architecture: | Unknown/Multiple | Difficulty: Easy (less | than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by hvr): wait a minute... why did you resubmit this? wasn't this already handled by #9004? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 10:34:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 10:34:06 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.cb271442f24db65ab346e5b544d7824b@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:37 rwbarton]: It still would not work: 1) the following script does not compile 2) I DO want to determine the output type based on the input types - I really want to introduce there fundep. I mean - I want to be able to write `tst a = property (property a)` and use it as `tst X` and get `Z` as the result. Additional - this is only one of the exampels we are using the extension. There are some other places where it works quite well. I do not know if here is the best place to discuss possible workarounds (but I'm very happy and thankfull to hear suggestions)? Anyway, I post the code I mentioned above: {{{#!haskell {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE AllowAmbiguousTypes #-} class Property a b where property :: a -> b data X = X data Y = Y deriving Show data Z = Z deriving Show instance (y ~ Y) => Property X y where property _ = Y instance (z ~ Z) => Property Y z where property _ = Z tst :: forall a s b. (Property a s, Property s b) => a -> b tst a = property (property a :: s) main = do print (property $ property X) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 10:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 10:36:43 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 Message-ID: <046.a5e1a230c427f830077792eaeef81556@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- concurrent/should_test/AtomicPrimops test fails on 32-bit archs as reported on the mailing list by P?li G?bor J?nos [http://www.haskell.org/pipermail/ghc-devs/2014-July/005706.html]. More info: AtomicPrimOps.hs flakes out for: fetchAndTest fetchNandTest fetchOrTest fetchXorTest casTest but not for fetchAddSubTest and readWriteTest. If I step through it, the segfault comes at line 166, it doesn't reach the .fetchXXXIntArray function that was called from the thread (at least ghci doesn't hit a breakpoint set at it). GDB says the bad instruction is: 4475: f0 8b 4c 24 40 lock mov 0x40(%esp),%ecx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 10:40:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 10:40:51 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.4c8e1b4683a9e13c18794e5ca93cab4b@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: Phab:D87 | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: T9156 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D87 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 11:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 11:08:46 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.4a4a1a0daefd184c02fe0233182ab2c2@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by simonpj): Several points * Your script in comment:37 typechecks just fine if you use `-XScopedTypeVariables`. You need the 's' in the body of `tst` to be the same as the one in the type signature. * Interestingly in this example, unlike earlier ones, the instances for `Property` really do morally satisfy the (liberal) Coverage condition: the first parameter determines the second. And GHC knows this. For example, this is accepted right now (with `UndecidableInstances` so that we get the liberal coverage condition): {{{ class Property a b | a -> b where -- Note the fundep property :: a -> b instance (y ~ Y) => Property X y where -- Suppose this was accepted property _ = Y }}} And now you don't need the `:: s` signature in the body of `tst` * It's also worth remembering that ALL fundeps do in GHC is guide the type inference engine. And you can offer the same guidance via type signatures. So you should be alle to fix your 600-module system by adding some type signatures. * Martin's excellent example, explained in detail in comment:30, is a pretty convincing reason for not rushing ahead with lifting the coverage condition altogether, especially given that there is another workaround (type signatures). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 11:09:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 11:09:18 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.c8b720f906a0cf14456b312cbcc70cc4@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 11:23:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 11:23:52 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.3c66301737e461851178c8ad5049d7f2@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by pgj): * cc: pgj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 11:35:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 11:35:34 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.42cb3c4fc0995867632b4125c36f5fe2@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tibbe): The `mov` instruction doesn't support a lock prefix. From: "Intel? 64 and IA-32 ArchitecturesSoftware Developer?s Manual": > The LOCK prefix can be prepended only to the following instructions and only to those forms of the instructions where the destination operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. If the LOCK prefix is used with one of these instructions and the source operand is a memory operand, an undefined opcode exception (#UD) may be generated. An undefined opcode exception will also be generated if the LOCK prefix is used with any instruction not in the above list. The XCHG instruction always asserts the LOCK# signal regardless of the presence or absence of the LOCK prefix However, I cannot see a place where we're adding one in the x86 codegen: https://github.com/ghc/ghc/blob/master/compiler/nativeGen/X86/CodeGen.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 11:39:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 11:39:49 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.293b1a8f097d1dfb10818f146e6415ea@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by pgj): I may be wrong here, but looks like the native code generator generates bad code. The {{{lock cmpxchg}}} instruction appears to be interleaved with the preceding {{{mov}}} instruction, hence {{{lock mov}}} is got. For {{{AtomicPrimops}}}, the following snippet is present in the generated assembly code: {{{ .Ln3sa: movl %ecx,64(%esp) movl %eax,%ecx movl %edx,76(%esp) movl %eax,%edx movl %ecx,88(%esp) movl 76(%esp),%ecx xorl %ecx,%edx lock movl 64(%esp),%ecx cmpxchgl %edx,(%ecx) jne .Ln3sd movl 88(%esp),%eax movl $ghczmprim_GHCziTuple_Z0T_closure+1,%esi jmp *(%ebp) .Ln3sd: movl 76(%esp),%edx jmp .Ln3sa }}} According to the sources, this does not seem to be intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 12:04:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 12:04:42 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.d7919a84ab160c59c6931b3260aa0a9d@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:39 simonpj]: 1) Of course - you are right - with `-XScopedTypeVariables` it does compile and works well - please forgot me, I overlooked the flag. 2) Yes this example satisfies the Coverage Condition, but as I described before it is just another simplification of some problem and in general we got instances which satisfy and which does not the condition. 3) There is other problem with providing such types by hand - we are generating the code and it would be very hard to generate such annotations in general. @rwbarton: Thank you again for your example - of course it works as you described. Still, while it needs some type signatures, they are hard for us to generate (while we are generating the Haskell's code). I think introducing optional `-XDysfunctionalDependencies` flag even as a local flag or using `~>` symbol, as Simon suggested above, would be a great thing - allowing to play with type system and creating easier some "hackish" things if user wishesh to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 12:54:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 12:54:21 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.29ad3a32e48b753b001327d79b836207@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by goldfire): I have another use case for dysfunctional dependencies. While I agree that the problem could be solved "just with type annotations", the burden would be quite high: {{{#!haskell {-# LANGUAGE RebindableSyntax, MultiParamTypeClasses, FlexibleInstances, AllowAmbiguousTypes, FunctionalDependencies #-} module PolyMonad where import Prelude hiding (Monad(..)) -- normal, "monomorphic" monads class Monad m where return :: a -> m a bind :: m a -> (a -> m b) -> m b fail :: String -> m a -- Morph m1 m2 means that we can lift results in m1 to results in m2 class Morph m1 m2 where morph :: m1 a -> m2 a -- Three monads form a polymonad when we can define this kind of -- bind operation. The functional dependency is very much meant to -- be *dys*functional, in that GHC should use it only when it has -- no other means to determine m3. class PolyMonad m1 m2 m3 | m1 m2 -> m3 where (>>=) :: m1 a -> (a -> m2 b) -> m3 b -- This is my desired instance, rejected (quite rightly) by the coverage -- condition: -- instance (Morph m1 m3, Morph m2 m3, Monad m3) => PolyMonad m1 m2 m3 where -- ma >>= fmb = bind (morph ma) (morph . fmb) -- an example of this in action: newtype Id a = Id a instance Monad Id where return = Id bind (Id x) f = f x fail = error instance Morph m m where morph = id -- Without the fundep on PolyMonad, `f` cannot type-check, -- even with a top-level type signature, because of inherent -- ambiguity. f x y z = do a <- x b <- y a z b }}} Instead of using fancy rebindable syntax, I could write out my definition for `f`, put in lots of type annotations with lots of scoped type variables, and get away with it all. But that's quite a dissatisfying answer here. One of the key reasons why I'm OK with dysfunctionality here is that there is an (unenforced) expectation of coherence among `Morph` instances. That is, if we have `Morph m1 m2` and `Morph m2 m3`, I expect also to have `Morph m1 m3` such that `morph == morph . morph`, if you follow my meaning. Without this coherence, the dysfunctionality is indeed disastrous... but, I believe that `Morph` coherence would allow the code above to work nicely. This is why I've always seen dysfunctional dependencies to be quite like incoherent instances. We're asking GHC to care less about consistency so that we, the programmer, can care more. Following this further, I disagree with Martin in comment:33 saying that we insist on consistency. He gives the following example: {{{#!haskell class C a b | a -> b instance C Int Bool instance C Int Char }}} In a dysfunctional world, what's wrong with this? It absolutely does mean that if GHC has to satisfy `C Int x`, an arbitrary and fragile choice will be made. But it also means that GHC can satisfy both `C Int Bool` and `C Int Char` if it needs to. It's up to the programmer to ensure that the implementations of the instances obey some set of properties so that the program's behavior is not fragile. This seems like a reasonable burden to me. danilo2, does my example above work with your `DysfunctionalDependencies`, with the instance put in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 13:09:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 13:09:36 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.bc4f3078adfb36841a78f86ec7f68615@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (CodeGen) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by schyler): +1, but please benchmark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 13:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 13:31:14 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.b6f89130ae534d2edcd87f6b75b59ccd@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:41 goldfire]: It deos not, but from simple reason. Your instance for PolyMonad does not specify what is the `m3` in any sense. I mean - you are using `(morph ma)` and `(morph . fmb)`. According to open world assumption, anybody can create any instance for `Morph` class, which is NOT injective, so we get here disambigous types: {{{#!haskell Could not deduce (Monad m20) arising from the ambiguity check for ?f? from the context (Monad m3, Monad m2, Morph m5 m2, Morph m4 m2, Morph m2 m3, Morph m1 m3) bound by the inferred type for ?f?: (Monad m3, Monad m2, Morph m5 m2, Morph m4 m2, Morph m2 m3, Morph m1 m3) => m1 t -> (t -> m4 t1) -> (t1 -> m5 b) -> m3 b at Tmp.hs:(44,1)-(46,16) The type variable ?m20? is ambiguous When checking that ?f? has the inferred type f :: forall t (m1 :: * -> *) (m2 :: * -> *) (m3 :: * -> *) b t1 (m4 :: * -> *) (m5 :: * -> *). (Monad m3, Monad m2, Morph m5 m2, Morph m4 m2, Morph m2 m3, Morph m1 m3) => m1 t -> (t -> m4 t1) -> (t1 -> m5 b) -> m3 b Probable cause: the inferred type is ambiguous }}} But your example can be easly fixed by defining any hints and NOT using `-XDysfunctionalDependencies` like this: {{{#!haskell {-# LANGUAGE RebindableSyntax, MultiParamTypeClasses, FlexibleInstances, AllowAmbiguousTypes, FunctionalDependencies, NoMonomorphismRestriction, ScopedTypeVariables, UndecidableInstances #-} module PolyMonad where import Prelude hiding (Monad(..)) -- normal, "monomorphic" monads class Monad m where return :: a -> m a bind :: m a -> (a -> m b) -> m b fail :: String -> m a -- Morph m1 m2 means that we can lift results in m1 to results in m2 class Morph m1 m2 where morph :: m1 a -> m2 a -- Three monads form a polymonad when we can define this kind of -- bind operation. The functional dependency is very much meant to -- be *dys*functional, in that GHC should use it only when it has -- no other means to determine m3. class PolyMonad m1 m2 m3 | m1 m2 -> m3 where (>>=) :: m1 a -> (a -> m2 b) -> m3 b -- This is my desired instance, rejected (quite rightly) by the coverage -- condition: class (Monad m1, Monad m2, Monad m3) => MatchMonad m1 m2 m3 | m1 m2 -> m3 instance (Morph m1 m3, Morph m2 m3, Monad m3, MatchMonad m1 m2 m3) => PolyMonad m1 m2 m3 where ma >>= fmb = bind (morph ma) (morph . fmb) -- ma >>= fmb = bind (matchMonad (morph ma) (undefined:: )) (morph . fmb) -- an example of this in action: newtype Id a = Id a instance Monad Id where return = Id bind (Id x) f = f x fail = error instance Morph m m where morph = id -- Without the fundep on PolyMonad, `f` cannot type-check, -- even with a top-level type signature, because of inherent -- ambiguity. f x y z = do a <- x b <- y a z a }}} Still, I completely agree with all the things you stated in your post. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 13:36:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 13:36:56 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.15465ffae5aea800c29810c87442b520@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not sure I understand comment:42, danilo2. The error you have toward the beginning of the comment is what I see when I leave out the fun-dep on `PolyMonad`. It doesn't seem related to my commented-out instance. Or, does un-commenting out the instance really produce that error? That's something strange. And, the `MatchMonad` idea just seems to kick the can down the road a bit: how could we have my desired instance for `MatchMonad` without `DysfunctionalDependencies`? Yes, `f` will type-check, but it won't be able to be called. Or am I deeply confused? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 15:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 15:07:00 -0000 Subject: [GHC] #9347: forkProcess does not acquire global handle locks Message-ID: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> #9347: forkProcess does not acquire global handle locks -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The global I/O handles (`stdout`, `stdin`, `stderr`) all make use an `MVar` wrapping a `Handle__`, and many I/O functions temporarily take this `MVar` (for instance, functions such as `hPutStr` include a call to `wantWritableHandle`, which uses `withHandle_'`, which involves taking the `MVar`, executing some operation, and then putting the `MVar` back). Suppose we have a program consisting of two threads A and B, where thread A is doing I/O. If thread B does a call to `forkProcess` then it is possible that the `fork()` happens at the point that A has just taken, say, the `MVar` for `stdout`. If this happens, every use of `stdout` in the child process will now forever deadlock. This is not a theoretical scenario. The example code reported by Michael Snoyman a few years ago http://www.haskell.org/pipermail/haskell-cafe/2012-October/103922.html exhibits precisely this behaviour: the child process deadlocks (not all the the time, but very frequently), exactly because of this problem. In `forkProcess` we avoid this sort of situation for all of the global RTS locks by acquiring the lock just before the call to `fork()`, and then releasing the lock in the parent again and re-initializing the lock in the child. But there are no provisions for Haskell-land locks such as the above `MVar`. In principle we can work around this problem entirely in user-land. Here is a modified version of Michael's code that does not deadlock (at least, it never has in my tests..), that basically takes the same acquire- release*2 trick that `forkProcess` does for RTS locks in the lines marked `(*)`: {{{ import System.Posix.Process (forkProcess, getProcessID) import Control.Concurrent (forkIO, threadDelay) import System.IO (hFlush, stdout) import System.Posix.Signals (signalProcess, sigKILL) import Control.Exception (finally) import Control.Concurrent import GHC.IO.Handle.Types import System.IO main :: IO () main = do mapM_ spawnChild [1..9] ioLock <- lockIO -- (*) child <- forkProcess $ do unlockIO ioLock -- (*) putStrLn "starting child" hFlush stdout loop "child" 0 unlockIO ioLock -- (*) print ("child pid", child) hFlush stdout -- I've commented out the "finally" so that the zombie process stays alive, -- to prove that it was actually created. loop "parent" 0 -- `finally` signalProcess sigKILL child spawnChild :: Int -> IO () spawnChild i = do _ <- forkIO $ loop ("spawnChild " ++ show i) 0 return () loop :: String -> Int -> IO () loop msg i = do pid <- getProcessID print (pid, msg, i) hFlush stdout threadDelay 1000000 loop msg (i + 1) -------------------------------------------------------------------------------- lockIO :: IO Handle__ lockIO = case stdout of FileHandle _ m -> takeMVar m unlockIO :: Handle__ -> IO () unlockIO hout = case stdout of FileHandle _ m -> putMVar m hout }}} I guess that _any_ global `MVar` or `TVar` is suspect when using `forkProcess`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 15:13:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 15:13:28 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.99ed5c4fccfb21d15c163c3ae21401b5@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire Comment: Our current solution seems workable, albeit not terribly principled. Cost is low, but benefits seem tangible. Richard (who owns this ticket anyway) is willing to implement this before 7.10. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 15:14:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 15:14:40 -0000 Subject: [GHC] #9347: forkProcess does not acquire global handle locks In-Reply-To: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> References: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> Message-ID: <059.34437abf038c0acbc743e85530d42912@haskell.org> #9347: forkProcess does not acquire global handle locks -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: michael@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 15:16:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 15:16:36 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.0701f680e6e1260b37d2d2ee14d07c6c@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tibbe): Aside: I've confirmed that loads don't need any kind of fences but we need an `mfence` for stores, which we don't have currently. You can see GCC outputting one here: {{{ #include void f(atomic_int* obj, int val) { return atomic_store(obj, val); } }}} Output: {{{ .file "repro.c" .text .globl f .type f, @function f: .LFB0: .cfi_startproc movl %esi, (%rdi) mfence ret .cfi_endproc .LFE0: .size f, .-f .ident "GCC: (GNU) 4.9.1" .section .note.GNU-stack,"", at progbits }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 16:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 16:11:07 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.7445628cd746ae294ff3ea981f971eac@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by niklasl): Seems like the lock gets separated from the compxchg somewhere in the register allocation. I don't know why it's treated as a separate instruction, I can't think of a case where you wouldn't want it glued to the parent instruction. And the move looks bogus too, ecx and that stack slot already contains the same stuff. {{{ ==================== Native code ==================== movl %vI_c2eB,%vI_n2tm movl %vI_c2eA,%vI_n2tn movl %vI_n2tn,%eax lock cmpxchgl %vI_n2tm,(%vI_n2tl) movl %eax,%vI_s1Rr movl %vI_s1Rr,%vI_s1Ru jmp _c2eD }}} {{{ ==================== Liveness annotations added ==================== movl %vI_c2ez,%vI_n2tl # born: %vI_n2tl # r_dying: %vI_c2ez movl %vI_c2eB,%vI_n2tm # born: %vI_n2tm # r_dying: %vI_c2eB movl %vI_c2eA,%vI_n2tn # born: %vI_n2tn # r_dying: %vI_c2eA movl %vI_n2tn,%eax # born: %r0 # r_dying: %vI_n2tn lock cmpxchgl %vI_n2tm,(%vI_n2tl) # r_dying: %vI_n2tl %vI_n2tm movl %eax,%vI_s1Rr # born: %vI_s1Rr # r_dying: %r0 movl %vI_s1Rr,%vI_s1Ru # born: %vI_s1Ru # r_dying: %vI_s1Rr jmp _c2eD # r_dying: %vI_s1Ru }}} {{{ ==================== Registers allocated ==================== movl 88(%esp),%ecx movl %eax,100(%esp) movl %ecx,%eax lock movl 100(%esp),%ecx cmpxchgl %ecx,(%edx) jmp _c2eD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 16:43:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 16:43:34 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.783f3a7640128a76858f5c6436daa625@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by pgj): I have written a simple patch to implement the strict pairing with the LOCK prefix. It almost works, but some of the tests (of ways {{{ghci}}} and {{{threaded2}}}) are still failing with this one, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 18:09:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 18:09:57 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.115f51c7efffafe62c0a917477d206fa@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tibbe): The only reason `LOCK` is a separate instruction is that I wanted to avoid adding e.g. a separate `Bool` argument to the e.g. the `MOV` constructor, as I would have to fix *all* uses of that instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 18:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 18:15:30 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.ad1870fad96fe70ceea3b171bdaf0146@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by niklasl): I think the patch is a nice way to solve that problem, have the LOCK take the instruction to be modified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 19:23:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 19:23:46 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.9ca24a6d84159406ba1a3efd7e557f7d@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tibbe): That indeed looks much nicer. What are the validate issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 19:25:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 19:25:14 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.2e9b8e1a3e37be4cc934264492f578d5@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 nomeata]: > I would find it strange to add such complexity ?just for? `inits`. Now, if we had such a `Queue` type (which looks useful in general) in base anyways, using it would be a different story... If it were added, it wouldn't be called `Queue`, because (unlike the real banker's queue) it's actually incapable of implementing `uncons` efficiently. It's really just a very limited, but very fast and light, list builder. If it's useful for things other than implementing `inits`, I would not be opposed to adding it in a separate module with some sufficiently clear name. I don't know enough about what sorts of things should and should not be provided by base to really comment much beyond that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 19:35:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 19:35:31 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.192a3f6c414d472643dfb5aa06f27a83@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: Phab:D69 | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1241, | #2247, #8356, #9103, #9227 | -------------------------------------+------------------------------------- Comment (by sulzmann): Regarding dropping the Consistency Condition (comment:41) Well, that's the minimal requirement I demand to call something Functional Dependencies. Oh, I see we are in the DysfunctionalDependencies world :) I'm also more than curious how to establish type safety without this requirement. What I'm describing in comment:33 are various forms of (type safe) Functional Dependencies where 'predictability' of type inference decreases the more we relax the coverage criteria. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 20:20:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 20:20:01 -0000 Subject: [GHC] #9348: "Symbol not found" when using a shared library Message-ID: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> #9348: "Symbol not found" when using a shared library -----------------------------------+----------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------------- I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 20:30:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 20:30:10 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.2302c2c73b68fbc6977f42b72023f1d5@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by pgj): The first one is that: {{{ $ make TEST=AtomicPrimops WAY=ghci ... =====> AtomicPrimops(ghci) 41 of 93 [0, 0, 0] cd . && inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-ghci-history AtomicPrimops.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS AtomicPrimops.interp.stdout 2>AtomicPrimops.interp.stderr Wrong exit code (expected 0 , actual 132 ) Stdout: fetchAddSubTest: OK Stderr: *** unexpected failure for AtomicPrimops(ghci) ... }}} That is, GHCi cannot run {{{AtomicPrimops}}}. Perhaps that is due to the byte code generation, I could not really find the exact reason. The other one is that: {{{ $ make TEST=AtomicPrimops WAY=threaded2 ... =====> AtomicPrimops(threaded2) 41 of 93 [0, 0, 0] cd . && inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-ghci-history -o AtomicPrimops AtomicPrimops.hs -O -threaded -eventlog >AtomicPrimops.comp.stderr 2>&1 cd . && ./AtomicPrimops +RTS -N2 -ls -RTS AtomicPrimops.run.stdout 2>AtomicPrimops.run.stderr Actual stdout output differs from expected: --- ./AtomicPrimops.stdout 2014-07-22 01:03:55.843169393 +0000 +++ ./AtomicPrimops.run.stdout 2014-07-22 20:26:04.769552990 +0000 @@ -1,6 +1,8 @@ fetchAddSubTest: OK fetchAndTest: OK -fetchNandTest: OK +fetchNandTest: FAIL +Expected: 1717991287 + Actual: -1431651397 fetchOrTest: OK fetchXorTest: OK casTest: OK *** unexpected failure for AtomicPrimops(threaded2) ... }}} That is, the NAND atomic does not work properly when {{{AtomicPrimops}}} is run with multiple threads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 20:32:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 20:32:03 -0000 Subject: [GHC] #9348: "Symbol not found" when using a shared library In-Reply-To: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> References: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> Message-ID: <064.1d7e0a9e8085dbe2d9cf60dff544065f@haskell.org> #9348: "Symbol not found" when using a shared library -----------------------------------------+--------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: MacOS X Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------------+--------------------------------- Description changed by alex.davis: Old description: > I'm trying to make a shared library from a simple program. It works fine > on my Windows box, but gives an error on Mac OS X. Furthermore, the error > seems to be generated from one of GHC's shared libraries. > > What happens is this. I compile my shared library with GHC, which works > fine. But when I try to use it from another program (specifically, R), I > get an error message containing the following: > Symbol not found: _stg_IND_STATIC_info > Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > Expected in: flat namespace > in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > > More details: > The program I'm trying to use is R. In R, you load a shared library with > the command "dyn.load". When I try this, the command I use is > "dyn.load('final.dylib')", and the full error message is what follows: > --- > Error in dyn.load("final.dylib") : > unable to load shared object '/Users/alexanderdavis/Desktop/illustrate > bug copy/final.dylib': > dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, > 6): Symbol not found: _stg_IND_STATIC_info > Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > Expected in: flat namespace > in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > --- > > As I said, I have done all of this with no trouble on Windows. I compiled > into a DLL, loaded the program into R, and was able to use the functions > in it. > > My Mac OS version is 10.9.4. > > My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- > darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. > > Command used for compiler: > ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib > > The code is attached. It is from a blog post by Neil Mitchelll (author of > HLint) about calling Haskell from R: > http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html New description: I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. However, on Windows I was also using an older version of GHC, and may have used the Haskell Platform and thus had more libraries installed - I don't have the computer iwth me, so I'm not sure. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 20:32:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 20:32:24 -0000 Subject: [GHC] #9348: "Symbol not found" when using a shared library In-Reply-To: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> References: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> Message-ID: <064.0e1022737645cd0af951fc3df88fbf41@haskell.org> #9348: "Symbol not found" when using a shared library -----------------------------------------+--------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: MacOS X Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------------+--------------------------------- Description changed by alex.davis: Old description: > I'm trying to make a shared library from a simple program. It works fine > on my Windows box, but gives an error on Mac OS X. Furthermore, the error > seems to be generated from one of GHC's shared libraries. > > What happens is this. I compile my shared library with GHC, which works > fine. But when I try to use it from another program (specifically, R), I > get an error message containing the following: > Symbol not found: _stg_IND_STATIC_info > Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > Expected in: flat namespace > in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > > More details: > The program I'm trying to use is R. In R, you load a shared library with > the command "dyn.load". When I try this, the command I use is > "dyn.load('final.dylib')", and the full error message is what follows: > --- > Error in dyn.load("final.dylib") : > unable to load shared object '/Users/alexanderdavis/Desktop/illustrate > bug copy/final.dylib': > dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, > 6): Symbol not found: _stg_IND_STATIC_info > Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > Expected in: flat namespace > in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- > prim-0.3.1.0-ghc7.8.3.dylib > --- > > As I said, I have done all of this with no trouble on Windows. I compiled > into a DLL, loaded the program into R, and was able to use the functions > in it. However, on Windows I was also using an older version of GHC, and > may have used the Haskell Platform and thus had more libraries installed > - I don't have the computer iwth me, so I'm not sure. > > My Mac OS version is 10.9.4. > > My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- > darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. > > Command used for compiler: > ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib > > The code is attached. It is from a blog post by Neil Mitchelll (author of > HLint) about calling Haskell from R: > http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html New description: I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. However, on Windows I was also using an older version of GHC, and may have used the Haskell Platform and thus had more libraries installed - I don't have the computer with me, so I'm not sure. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 22 20:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jul 2014 20:48:36 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.c38fb94b94fa96df66b7b2ed3344a869@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by blitzcode): (I knew about that switch, but I didn't know how to install a package for my freshly build GHC without interfering with my normal package database. I found some instructions on the GHC wiki for avoiding this issue, though. Apologies for missing them the first time around...) I get the same result as you, the warning seems to be gone. Thanks a lot! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 00:57:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 00:57:12 -0000 Subject: [GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons In-Reply-To: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> References: <048.d2a4fc9b0ec433d884d95f7df68fa955@haskell.org> Message-ID: <063.2c158c691c5e0054792cbc3ab324a596@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------+------------------------------------------------- Reporter: | Owner: blitzcode | Status: closed Type: bug | Milestone: 7.10.1 Priority: | Version: 7.8.3 normal | Keywords: Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Resolution: | compile-time duplicate | Test Case: Differential: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8848 | -------------------------+------------------------------------------------- Changes (by carter): * status: new => closed * resolution: => duplicate * related: => #8848 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 04:14:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 04:14:31 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.875617295c1143ad75c7ce678fd54853@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Differential: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Comment (by JohnWiegley): hvr, you're right, this is a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 04:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 04:18:58 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining Message-ID: <047.59a8e661fb91965de593a33a83b24298@haskell.org> #9349: excessive inlining with -fpre-inlining --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ The program at https://gist.github.com/jorendorff/a3005968adc8f054baf7 runs very slowly when compiled with `-O` or higher. It seems that `arr` and/or `rangeMap` is being inlined into the do block on lines 89-91 and recomputed for each iteration of the loop. The program runs nearly instantly when compiled with `-O0` or with `-O -fno-pre-inlining`. (Of course, this does not mean `-fpre-inlining` is necessary the culprit; it could be enabling some subsequent misoptimization.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 06:02:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 06:02:51 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.289ddfad5d5c213f60da1cdaf37f28c7@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Differential: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 7.8.4 Comment: I'm taking the liberty of setting an early milestone for this one because the current situation is silly and the change is entirely local. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 06:03:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 06:03:15 -0000 Subject: [GHC] #9337: Add `sortOn` function to Data.List In-Reply-To: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> References: <050.f23201fa5a59827d90399061f435c9f1@haskell.org> Message-ID: <065.3be5391f640fc39a50cdb686f778d63a@haskell.org> #9337: Add `sortOn` function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Resolution: duplicate | Keywords: Differential: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #9004 | Test Case: | Blocking: -------------------------------------------+------------------------------- Changes (by hvr): * status: new => closed * resolution: => duplicate * related: => #9004 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 07:25:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 07:25:00 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.36128f5396c8546293192a4419141972@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Indeed, when bootstrapping with 7.6.3, the dependency files in a GHC build have unnecessary entries due to `-dep-suffix ""`: {{{ # DO NOT DELETE: Beginning of Haskell dependencies utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/HSCParser._o : utils/hsc2hs/HSCParser.hs $(eval $(call hi-rule,utils/hsc2hs/dist/build/HSCParser.hi utils/hsc2hs/dist/build/HSCParser._hi : %hi: %o utils/hsc2hs/HSCParser.hs)) utils/hsc2hs/dist/build/HSCParser.o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Prelude.hi utils/hsc2hs/dist/build/HSCParser._o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Prelude._hi utils/hsc2hs/dist/build/HSCParser.o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Data/Char.hi utils/hsc2hs/dist/build/HSCParser._o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Data/Char._hi utils/hsc2hs/dist/build/HSCParser.o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Control/Monad.hi utils/hsc2hs/dist/build/HSCParser._o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Control/Monad._hi utils/hsc2hs/dist/build/HSCParser.o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Control/Applicative.hi utils/hsc2hs/dist/build/HSCParser._o : /home/smarlow/local/lib/ghc-7.6.3/base-4.6.0.1/Control/Applicative._hi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 07:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 07:29:53 -0000 Subject: [GHC] #9287: changed dependency generation In-Reply-To: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> References: <045.192efe9143fad99b3d651cfd573821dc@haskell.org> Message-ID: <060.c3c1bc93d192963d6d44d64211f20994@haskell.org> #9287: changed dependency generation -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Change that broke this: #7381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 07:41:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 07:41:24 -0000 Subject: [GHC] #9342: Branchless arithmetic operations In-Reply-To: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> References: <042.f67bcd0b7fa4756968d496283e13dc83@haskell.org> Message-ID: <057.675d987fe1af66ea540713b83f412694@haskell.org> #9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (CodeGen) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Same here: +1 but benchmark. Based on my experience from #6135 I don't expect to see much performance improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 08:16:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 08:16:01 -0000 Subject: [GHC] Password reset for user: hvr Message-ID: <20140723081601.701A92406B@ghc.haskell.org> Password reset for user for user hvr -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 08:16:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 08:16:21 -0000 Subject: [GHC] Password reset for user: hvr Message-ID: <20140723081621.727982406B@ghc.haskell.org> Password reset for user for user hvr -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 08:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 08:23:02 -0000 Subject: [GHC] Password reset for user: hvr Message-ID: <20140723082302.8BB372406B@ghc.haskell.org> Password reset for user for user hvr -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 08:23:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 08:23:16 -0000 Subject: [GHC] Password reset for user: hvr Message-ID: <20140723082316.5B6E42406B@ghc.haskell.org> Password reset for user for user hvr -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 08:41:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 08:41:22 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.8b01910b5eed6f9b71d57f0fb8d2b22c@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:4 dfeuer]: > Replying to [comment:1 nomeata]: > > > I would find it strange to add such complexity ?just for? `inits`. Now, if we had such a `Queue` type (which looks useful in general) in base anyways, using it would be a different story... > > If it were added, it wouldn't be called `Queue`, because (unlike the real banker's queue) it's actually incapable of implementing `uncons` efficiently. It's really just a very limited, but very fast and light, list builder. If it's useful for things other than implementing `inits`, I would not be opposed to adding it in a separate module with some sufficiently clear name. I don't know enough about what sorts of things should and should not be provided by base to really comment much beyond that. After reading more of the code I agree that this not too big ?just for? inits, and I?m in favor of adding it. I also thought about ways to make it even faster. In particular, I tried to make `GHC` get rid of `Queue` and simply pass the three values around as arguments to the inner loop, and also make this fuse. With this definition it works: {{{ myScanl' :: (b -> a -> b) -> b -> [a] -> [b] myScanl' f a bs = build $ \c n -> a `seq` a `c` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `c` g b'))) (\b -> b `seq` n) bs a initsQ2 :: [a] -> [[a]] initsQ2 = map toListQ . myScanl' snocQ emptyQ }}} and yields consistently better results than `initsQ`. (See attached report, `initsQ2`. Ignore `initsQDL`, thats the same, but with the rear list implemented as a difference list, which makes little difference.) This raises the question whether we want such a fusing strict `scanl'` in `Data.List` as well ? it turned out to be useful here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 09:20:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 09:20:37 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.99c2a271c4d88a6aaa52372020a7a0ea@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): I'm looking into the test failures. The `ghci` way does pass for me, on a 64-bit Linux machine. `fetchNandTest` fails for me as well. I will look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 09:56:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 09:56:24 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.7c8d776c9aca58219e6b374fb84d0347@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Figured it out. My test is wrong. `complement ((complement (n0 .&. t1pat)) .&. t2pat) /= complement ((complement (n0 .&. t2pat)) .&. t1pat)`, which the test asserted. Patch on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 10:11:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 10:11:07 -0000 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@haskell.org> References: <043.f6cbfda45c43862fefdcb63df98df61f@haskell.org> Message-ID: <058.67b1d2ab3e55990b4cf0678ee662898b@haskell.org> #311: gmp's memory management -------------------------------------+------------------------------------- Reporter: as49 | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.4 (FFI) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9281 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * failure: => None/Unknown * related: => #9281 Comment: See #9281 for a new attempt to improve the situation for the `integer-gmp` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 10:22:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 10:22:58 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.e5569c9372b0deb0e128da34c3a06a61@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:12 tibbe]: > The `ghci` way does pass for me, on a 64-bit Linux machine. I believe that will only fail on a 32-bit machine. I got that with FreeBSD/i386 ({{{-march=i686}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 10:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 10:30:36 -0000 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@haskell.org> References: <047.118762464fe3464def09b9461b8cccc5@haskell.org> Message-ID: <062.4c5bb545ffdb0b688dfd77f649457a99@haskell.org> #601: Replace GMP -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: fixed | Keywords: Integer-gmp gmp Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: | days) None/Unknown | Blocked By: Test Case: N/A | Related Tickets: #9281 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => Integer-gmp gmp * related: => #9281 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:26:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:26:18 -0000 Subject: [GHC] #9350: Consider using xchg instead of mfence for CS stores Message-ID: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> #9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- To get sequential consistency for `atomicWriteIntArray#` we use an `mfence` instruction. An alternative is to use an `xchg` instruction (which has an implicit `lock` prefix), which might have lower latency. We should check what other compilers do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:38:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:38:23 -0000 Subject: [GHC] #9350: Consider using xchg instead of mfence for CS stores In-Reply-To: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> References: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> Message-ID: <059.746e6e05bf59d84f3f6e8019805ca6aa@haskell.org> #9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Herb Sutter argues for using `xchg` over `mfence` in [http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb- Sutter-atomic-Weapons-2-of-2 C++ and Beyond 2012: Herb Sutter - atomic<> Weapons, 2 of 2], around 0:38:20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:42:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:42:49 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.f6820d1a769066ccfd82a60ce5e1df22@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): I've attached three patches that we should apply. The first one is pgj's patch, but as a git patch, the second fixes the incorrect test, and the third one adds a missing memory fence that I found. The three commits validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:44:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:44:43 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.274e683230a510471488fa9f7640dbf9@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:45:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:45:49 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.ada26304b0f4fcbcfd80dd444ddf127a@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Note that I haven't looked into the ghci issue, which I think is separate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 11:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 11:48:59 -0000 Subject: [GHC] #9350: Consider using xchg instead of mfence for CS stores In-Reply-To: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> References: <044.20ad8d34f8b6b8a13d3ff80072b8a8e7@haskell.org> Message-ID: <059.0bf8bf3aa7eabd69c09c98f676909959@haskell.org> #9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): GCC 4.9.1 does use `mfence`. This code {{{ #include void f(atomic_int* obj, int val) { return atomic_store(obj, val); } }}} generates this assembly {{{ .file "repro.c" .text .globl f .type f, @function f: .LFB0: .cfi_startproc movl %esi, (%rdi) mfence ret .cfi_endproc .LFE0: .size f, .-f .ident "GCC: (GNU) 4.9.1" .section .note.GNU-stack,"", at progbits }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 12:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 12:14:48 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.5fbafa1e7a83b8ebeba9d3f065d70371@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by niklasl): * priority: normal => highest Comment: Yeah, fixing the bad code generation shouldn't wait for that. Let's increase the priority too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 13:38:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 13:38:13 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.c2c8b0c833f06a49e87dfc72008bf928@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #1241, #2247, None/Unknown | #8356, #9103, #9227 Test Case: | Blocking: | Differential Revisions: Phab:D69 | -------------------------------------+------------------------------------- Comment (by danilo2): @goldfire: I'm out of the office right now - I've got to do something urgent today - in the evening I'll reply you with examples and my understanding of the things. I'm sorry for the delay - I 'll edit this comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 14:56:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 14:56:00 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.56595b928fc14ec50c99c6b36cca72a8@haskell.org> #9349: excessive inlining with -fpre-inlining -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by klao): * cc: klao@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 15:12:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 15:12:03 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.5cd775915a63c3dd2e1668fce5d72a23@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): That's a neat idea. If I'm not mistaken, `seq` in the argument to `build` leads to a proof obligation to justify the safety of the fusion. Do you have a proof? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 15:13:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 15:13:21 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.666bf69f9be45da0324cf36a288d6d4d@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > That's a neat idea. If I'm not mistaken, seq in the argument to build leads to a proof obligation to justify the safety of the fusion. Do you have a proof? No. What exactly is the proof obligation in this case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 15:22:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 15:22:50 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.2620ce735f1cc6f8df3b40fbc8d9900a@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I messed around with RULES a bit, and the following seem to work okay for starters. Some more rules will be needed to make map/takeWhile and takeWhile/map and whatever else do the right thing. One thing I'm not too clear about: what's the advantage of the explicitly recursive default definition over `takeWhile p = foldr (\x r -> if p x then x:r else []) []`? {{{ {-# INLINE [0] takeWhileFB #-} takeWhileFB :: (elt -> lst -> lst) -> lst -> (elt -> Bool) -> elt -> lst -> lst takeWhileFB kons knil p = \x rest -> if p x then x `kons` rest else knil {-# NOINLINE [1] takeWhile #-} takeWhile :: (a -> Bool) -> [a] -> [a] takeWhile _ [] = [] takeWhile p (x:xs) | p x = x : takeWhile p xs | otherwise = [] {-# RULES "takeWhile" [~1] forall p xs. takeWhile p xs = build (\kons knil -> foldr (takeWhileFB kons knil p) knil xs) "takeWhileList" [1] forall p. foldr (takeWhileFB (:) [] p) [] = takeWhile p "takeWhileFB" forall kons knil p q. takeWhileFB (takeWhileFB kons knil p) knil q = \x rest -> if (q x && p x) then x `kons` rest else knil #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 15:30:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 15:30:21 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.643b3f119fe302b51c5f6c0bed6d2513@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 nomeata]: > > That's a neat idea. If I'm not mistaken, seq in the argument to build leads to a proof obligation to justify the safety of the fusion. Do you have a proof? > > No. What exactly is the proof obligation in this case? According to the [http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion short cut fusion page] on the Haskell Wiki, the foldr/build equivalence in general is only guaranteed when the argument to build does not use `seq`; otherwise there are ways to break it so that the fused program is less lazy than it should be. That page gives one way around that limitation, which involves restricting the other arguments to `foldr`, but that's not an option here?a "bare" `build` is exposed to the world. So if I understand things right (which is never guaranteed at all), you're left having to write your own proof, from scratch or based on other theorems not mentioned on that page, that the foldr/build rule is safe here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 15:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 15:37:52 -0000 Subject: [GHC] #9344: takeWhile does not participate in list fusion In-Reply-To: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> References: <045.523942f2e550cc3c4b1504a35e9c0cd3@haskell.org> Message-ID: <060.84869e75f6ae81391e3d5b36fcf6631f@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > One thing I'm not too clear about: what's the advantage of the explicitly recursive default definition over takeWhile p = foldr (\x r -> if p x then x:r else []) [] Nothing per se, unless benchmarking shows that the explicit version is faster, I guess. It might even be that simply {{{ takeWhile p xs = build (\kons knil -> foldr (takeWhileFB kons knil p) knil xs) {-# INLINEABLE takeWhile #-} }}} is good enough, assuming the non-inlined `takeWhile` gets compiled to good code (i.e. `build`, `foldr` and `takeWhileFB` are inlined). But I don?t have much experiences to predict that, so you?ll have to experiment and look at core to find out -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 16:06:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 16:06:46 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code Message-ID: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's consider an example: We have a haskell package with some C code imported in haskell: {{{ // a.h file int get_something(void); // a.c file #include "a.h" int get_something(void) { return 42; } // M.hs file module M where foreign import ccall "a.h get_something" :: IO Int }}} The problem here is we can't mix that package with other packages having global 'get_something' symbol. Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols. Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible. Something like that: {{{ // a.h file #include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */ int FOR_HASKELL(get_something)(void); // a.c file #include "a.h" int FOR_HASKELL(get_something)(void) { return 42; } // M.hs file module M where foreign import ccall-for-haskell "a.h get_something" :: IO Int }}} That way we explicitly mark symbol as inaccessible to external plain C code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 17:12:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 17:12:59 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.aa2514a6c138123dfbcbfb8c308edfb2@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I'm also experiencing this problem. The problem affects GHC 7.8.2 and GHCi. I'm loading files using: : ghci[i] Foo Objects/*.o which fails: ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc20682_0/ghc20682_3.so: undefined symbol: foo If I explicitly list out each object file in the "correct" order, I can get GHC to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 17:13:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 17:13:39 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.66602ea39cac6d4c5aaac78f4ea18b2c@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: crockeea (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 17:51:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 17:51:39 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code In-Reply-To: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> References: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> Message-ID: <060.93b8d45a6095cf2e5bc156a1ca1519da@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, I'd rather have a macro for the `.hs` part as well than have yet another FFI calling convention. (it'd be useful in other cases as well, to have the ability to uniformly transform the ABI-level C symbol name; e.g. for GMP, all official function names are prefixed by `__g` prefix at the ABI level) E.g. something like: {{{#!hs foreign import ccall C_PKG_NAME("a.h","get_something") :: IO Int }}} This will, however, require a better CPP than the current traditional CPP mode to work... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 18:16:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 18:16:36 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.1933da4d1fee04d00e15237720e6462f@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tulcod): * cc: tulcod (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 18:17:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 18:17:08 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.4a342a6a2fba790ba15686361c4acdc9@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic Operating System: MacOS X | linking Type of failure: GHCi crash | Architecture: x86_64 (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: Differential Revisions: | Related Tickets: #8935, #9034, | #9074, #9278 -------------------------------------+------------------------------------- Changes (by tulcod): * cc: tulcod (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 18:26:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 18:26:43 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.e33b19ba8e595baf5c50a4fea174aada@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: lowest | Version: 7.6.3 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: ? => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 18:28:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 18:28:42 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.8b98f88ba1b672018952c1958bdc8714@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've worked on it a bit, and if I'm not mistaken, `myScanl'` is safe if, whenever `a /= _|_`, and however I choose `evil`, `wrong`, and `f`, the "correct" expression {{{ e1 = a `evil` foldr evil wrong $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' : g b'))) (\b -> b `seq` []) bs a }}} gives the same result as the fused expression {{{ e2 = a `evil` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `evil` g b'))) (\b -> b `seq` wrong) bs a }}} But I'm not sure how to prove this or find a counterexample. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 18:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 18:30:06 -0000 Subject: [GHC] #6050: Documentation for option -Wall and warning -fwarn-unrecognised-pragmas In-Reply-To: <042.0c4279c48f4565c6e3d424f5c423d40e@haskell.org> References: <042.0c4279c48f4565c6e3d424f5c423d40e@haskell.org> Message-ID: <057.deb225712c306b9eea79c23530f71498@haskell.org> #6050: Documentation for option -Wall and warning -fwarn-unrecognised-pragmas -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: | Version: 7.6.3 Documentation | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: ? => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:07:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:07:37 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports Message-ID: <042.badab7c0b70bc218549980e1ff162223@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket is to allowing code like {{{#!hs {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE MagicHash #-} module M where import GHC.Exts foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# s, Int# #) }}} See also discussion in #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:15:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:15:10 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.532f4bff4c6aac603b0498bd7366d73f@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9218 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): As first proof-of-concept, I made the type-checker allow `State# s` to see if it would just-work(tm), here's the Cmm output resulting from the `foo` declaration: {{{#!c [section "data" { M.c_foo_closure: const M.c_foo_info; }, M.c_foo_entry() // [R2] { info_tbl: [(c1Cx, label: M.c_foo_info rep:HeapRep static { Fun {arity: 2 fun_type: ArgSpec 4} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c1Cx: _s1Cl::I64 = R2; goto c1Cz; c1Cz: _c1Cv::I64 = foo; _c1Cw::I64 = _s1Cl::I64; call "ccall" arg hints: [?signed?] result hints: [] (_c1Cv::I64)(_c1Cw::I64); call (P64[Sp])() args: 8, res: 0, upd: 8; } }] }}} Compiling `bar` however, results in {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140723 for x86_64-unknown-linux): resultWrapper (# State# s, Int# #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:15:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:15:57 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.c9fbf68329dec2626ad89acb813d88a2@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * related: #9218 => #9281 Old description: > This ticket is to allowing code like > > {{{#!hs > {-# LANGUAGE UnliftedFFITypes #-} > {-# LANGUAGE MagicHash #-} > > module M where > > import GHC.Exts > > foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s > > foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# > s, Int# #) > }}} > > See also discussion in #9218 New description: This ticket is to allowing code like {{{#!hs {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module M where import GHC.Exts foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# s, Int# #) }}} See also discussion in #9281 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:17:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:17:07 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.8b5300c0185a54fabb247286b8bbdc13@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries | Version: (other) | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by hvr): Fyi, I've created a separate ticket #9352 to further discuss the `State# s`/FFI story -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:24:31 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful Message-ID: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I wanted to use GHC's new prefetch primops to speed up a cover tree data structure I've been working on. The current implementation, however, is insufficient. The pure primops do not work at all. I propose an alternative using a seq-like syntax. ------- **The problem** Consider the function: {{{ prefetchAddr3# :: Addr# -> Int# -> Addr# }}} It is used like: {{{ -- addr# :: Addr# let prefetchAddr# = prefetchAddr3# addr# 0 ... do some stuff not involving addr# doRealWork prefetchAddr# }}} The problem is that we want the prefetch operation to get inserted at the let statement before "do some stuff...", but it doesn't get inserted there. It gets inserted directly before the call to doRealWork. This doesn't give the prefetch enough time to actually put the memory in cache, and so we still get a cache miss. I made several attempts to get around this, but they all failed due to dead code elimination. The `prefetchMutableByteArray#` functions solve this problem by incorporating an explicit state parameter. This forces the compiler to insert the prefetch operation at the location it is actually called in the code. This function, however, can only be used within the ST and IO monads, so it is of limited use. ------ ** The solution** The solution is to restructure the pure primops to use a seq-like format. For example, the prefetchAddr3# function above would become: {{{ prefetchAddr3# :: Addr# -> a -> a }}} Then we would call the function like: {{{ prefetchAddr3# addr# someOtherOp ... do some stuff not involving addr# doRealWork prefetchAddr# }}} This would correctly insert the prefetch instruction at the location it appears in the haskell code. In particular, the prefetch will occur whenever the second parameter is evaluated. This format has the advantage that it can work in non-monadic code. In my cover tree structure, I've implemented searching the tree as a `fold` operation. Every time the fold branches, only one of the branches is guaranteed to be in the cache. So I get a cache miss when I go down the other branches. I want to use the prefetch primop to prefetch the next branch the fold will go down. The fold function is pure, and I don't want to have to wedge it into the ST monad just for prefetching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:27:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:27:51 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.31cf4b047211714de903f91252416820@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by MikeIzbicki: Old description: > I wanted to use GHC's new prefetch primops to speed up a cover tree data > structure I've been working on. The current implementation, however, is > insufficient. The pure primops do not work at all. I propose an > alternative using a seq-like syntax. > > ------- > **The problem** > > Consider the function: > > {{{ > prefetchAddr3# :: Addr# -> Int# -> Addr# > }}} > > It is used like: > > {{{ > -- addr# :: Addr# > > let prefetchAddr# = prefetchAddr3# addr# 0 > > ... do some stuff not involving addr# > > doRealWork prefetchAddr# > > }}} > > The problem is that we want the prefetch operation to get inserted at the > let statement before "do some stuff...", but it doesn't get inserted > there. It gets inserted directly before the call to doRealWork. This > doesn't give the prefetch enough time to actually put the memory in > cache, and so we still get a cache miss. I made several attempts to get > around this, but they all failed due to dead code elimination. > > The `prefetchMutableByteArray#` functions solve this problem by > incorporating an explicit state parameter. This forces the compiler to > insert the prefetch operation at the location it is actually called in > the code. This function, however, can only be used within the ST and IO > monads, so it is of limited use. > > ------ > ** The solution** > > The solution is to restructure the pure primops to use a seq-like format. > For example, the prefetchAddr3# function above would become: > > {{{ > prefetchAddr3# :: Addr# -> a -> a > }}} > > Then we would call the function like: > > {{{ > prefetchAddr3# addr# someOtherOp > > ... do some stuff not involving addr# > > doRealWork prefetchAddr# > }}} > > This would correctly insert the prefetch instruction at the location it > appears in the haskell code. In particular, the prefetch will occur > whenever the second parameter is evaluated. > > This format has the advantage that it can work in non-monadic code. In > my cover tree structure, I've implemented searching the tree as a `fold` > operation. Every time the fold branches, only one of the branches is > guaranteed to be in the cache. So I get a cache miss when I go down the > other branches. I want to use the prefetch primop to prefetch the next > branch the fold will go down. The fold function is pure, and I don't > want to have to wedge it into the ST monad just for prefetching. New description: I wanted to use GHC's new prefetch primops to speed up a cover tree data structure I've been working on. The current implementation, however, is insufficient. The pure primops do not work at all. I propose an alternative using a seq-like syntax. ------- **The problem** Consider the function: {{{ prefetchAddr3# :: Addr# -> Int# -> Addr# }}} It is used like: {{{ -- addr# :: Addr# let prefetchAddr# = prefetchAddr3# addr# 0 ... do some stuff not involving addr# doRealWork prefetchAddr# }}} The problem is that we want the prefetch operation to get inserted at the let statement before "do some stuff...", but it doesn't get inserted there. It gets inserted directly before the call to doRealWork. This doesn't give the prefetch enough time to actually put the memory in cache, and so we still get a cache miss. I made several attempts to get around this, but they all failed due to dead code elimination. The `prefetchMutableByteArray#` functions solve this problem by incorporating an explicit state parameter. This forces the compiler to insert the prefetch operation at the location it is actually called in the code. This function, however, can only be used within the ST and IO monads, so it is of limited use. ------ ** The solution** The solution is to restructure the pure primops to use a seq-like format. For example, the prefetchAddr3# function above would become: {{{ prefetchAddr3# :: Addr# -> Int# -> a -> a }}} Then we would call the function like: {{{ prefetchAddr3# addr# someOtherOp ... do some stuff not involving addr# doRealWork prefetchAddr# }}} This would correctly insert the prefetch instruction at the location it appears in the haskell code. In particular, the prefetch will occur whenever the second parameter is evaluated. This format has the advantage that it can work in non-monadic code. In my cover tree structure, I've implemented searching the tree as a `fold` operation. Every time the fold branches, only one of the branches is guaranteed to be in the cache. So I get a cache miss when I go down the other branches. I want to use the prefetch primop to prefetch the next branch the fold will go down. The fold function is pure, and I don't want to have to wedge it into the ST monad just for prefetching. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:32:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:32:12 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.8107afbe9236cb7836dd587a93c45c1a@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * owner: => carter * milestone: => 7.10.1 Comment: thanks for taking the time to writeup the design we discussed and motivate the change. I think this is a reasonable breaking change to make to the prefetch primops for the pure API, i'll get to it soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:50:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:50:11 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code In-Reply-To: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> References: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> Message-ID: <060.e378f13e683934a87d9cb29cfcc5c7e9@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Yeah, it's just an idea of symbol mangling control. Maybe macro introduction better be done on cabal's side? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:51:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:51:14 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.fffd70c41c0fa973c4dd9b2d9330ca9f@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): Fixed by 23773b25863a0a439d81332cb8eee14f6f2c0098 and c11b35f5c5efe8f11039583c493e245bb6bcb33c. While we haven't seen any failure due to it, fc53ed5da1a2455b0da2f8ef3ec317e1a96ed83d fixes an issue with a missing memory fence for stores. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:56:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:56:01 -0000 Subject: [GHC] #9354: AtomicPrimops tests failing on 32-bit x86 in ghci Message-ID: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> #9354: AtomicPrimops tests failing on 32-bit x86 in ghci ----------------------------+------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- pgj reports in #9346 that the AtomicPrimops test fails on 32-bit x86, when run under the ghci "way": {{{ $ make TEST=AtomicPrimops WAY=ghci ... =====> AtomicPrimops(ghci) 41 of 93 [0, 0, 0] cd . && inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-ghci-history AtomicPrimops.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS AtomicPrimops.interp.stdout 2>AtomicPrimops.interp.stderr Wrong exit code (expected 0 , actual 132 ) Stdout: fetchAddSubTest: OK Stderr: *** unexpected failure for AtomicPrimops(ghci) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:56:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:56:16 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.974965e1f69d79dad05fdae2b0e3c4d9@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): I moved the ghci issue to #9354. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 19:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 19:56:27 -0000 Subject: [GHC] #9346: AtomicPrimOps tests failing on 32-bit x86 In-Reply-To: <046.a5e1a230c427f830077792eaeef81556@haskell.org> References: <046.a5e1a230c427f830077792eaeef81556@haskell.org> Message-ID: <061.9a334361d679cf08d5fa3085ae1bdc88@haskell.org> #9346: AtomicPrimOps tests failing on 32-bit x86 -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 20:02:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 20:02:10 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.0e4a29e141c835d79bb27f1a2efb38e8@haskell.org> #9349: excessive inlining with -fpre-inlining -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Aha, it is the state hack marking the argument to `replicateM_` as one- shot, followed by pre-inlining. What was rather surprising to me as an end user was that `{-# NOINLINE rangeMap #-}` had no effect. I guess the pre-inlining does not care about such pragmas. Simon, any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 20:15:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 20:15:58 -0000 Subject: [GHC] #9354: AtomicPrimops tests failing on 32-bit x86 in ghci In-Reply-To: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> References: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> Message-ID: <059.1f3664a8e3f140033a42941224537d49@haskell.org> #9354: AtomicPrimops tests failing on 32-bit x86 in ghci -------------------------------------------+--------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Changes (by tibbe): * cc: niklasl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 21:55:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 21:55:24 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion Message-ID: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This should be a no-brainer?it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 22:01:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 22:01:34 -0000 Subject: [GHC] #9356: scanl does not participate in stream fusion Message-ID: <045.ab578058deeca9329303e3b009a823aa@haskell.org> #9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nomeata came up with a fusing version of a strict `scanl'` in a comment on #9345. It's not entirely clear to me whether that's entirely safe, but a non-strict version of it for `scanl` would be, as both a good producer and good consumer, presumably made efficient using the same sorts of magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to write as a good consumer; only the production side remains to be proved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 23 22:44:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jul 2014 22:44:18 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.5829a59cf943bcd70dc3b7e82602e9d9@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I forgot to attach the report mentioned in comment:6, doing that now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 01:14:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 01:14:07 -0000 Subject: [GHC] #9348: "Symbol not found" when using a shared library In-Reply-To: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> References: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> Message-ID: <064.b0bed82e1b72dcdc168e024f86c04886@haskell.org> #9348: "Symbol not found" when using a shared library -----------------------------------------+---------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+---------------------------- Comment (by alex.davis): Shea Levy figured out the problem and its solution. First of all, its not a problem with R, you get the same error from C. I've attached Shea's C code, which I've titled "errorFromC.c". This code tries to load the Haskell shared library, which it assumes is named "test.dylib", and gives the same error as R. Second, the problem is solved by adding to the compilation the flag "-lHSrts-ghc7.8.3". This links the Haskell runtime system to the resulting file. (although, on my computer I still get errors due to the use if Int instead of CInt in the Haskell code. But the problem of not being able to access the Haskell code at all is solved.) This represents a mismatch between the behavior of the compiler and its documentation. People looking to make shared libraries will read [https://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared- libs.html#idp12506320 section 4.13.3 of the GHC user's guide]. They will see "To build Haskell modules that export a C API into a shared library use the -dynamic, -fPIC and -shared flag". No mention of linking the runtime system. I'm not sure if this a problem with the compiler or the documentation, but either way it should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 02:41:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 02:41:18 -0000 Subject: [GHC] #9347: forkProcess does not acquire global handle locks In-Reply-To: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> References: <044.faeca2d8b88cc27819d6e9b9f2f3ebd0@haskell.org> Message-ID: <059.ba41ca375469870c99948673d98bc8d5@haskell.org> #9347: forkProcess does not acquire global handle locks -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 06:32:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 06:32:46 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.d49a4a152bb0d0d41ed48e6cece5fce7@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:11 nomeata]: > I forgot to attach the report mentioned in comment:6, doing that now. I was finally able to figure out how to read that file, and ''wow''. Those are some impressive results. If we can verify that the fusion on the left is safe, `initsQ2` is clearly the way to go. If we can't, it looks like we probably want to use the same thing, but without the `build`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 07:33:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 07:33:37 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.cc6016a18a9b60092d793ef81e078fa8@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Template | Version: 6.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9032 None/Unknown | Test Case: | TH_import_loop | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #9032 Comment: #9032 looks related (not sure if it's a duplicate or not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 07:34:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 07:34:08 -0000 Subject: [GHC] #9032: Panic with self-import In-Reply-To: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> References: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> Message-ID: <063.a39ae648e9546c9ab176a95103fbe42a@haskell.org> #9032: Panic with self-import -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #1012 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #1012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 10:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 10:10:42 -0000 Subject: [GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments Message-ID: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> #9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code is accepted by ghc-7.8.2 and ghc-7.6.3: {{{#!hs {-# LANGUAGE TypeFamilies, MagicHash, PolyKinds #-} import GHC.Exts type family F (a :: k) :: * type instance F Int# = () }}} In nearly all other places, it seems that unlifted types are explicitly forbidden. I'm also not allowed to actually apply `F` to `Int#` after defining the type family like this. So I think the compiler should probably reject the `type instance`. (BTW, is it actually clear that using `#` as an argument kind to a type family or as an index kind for a GADT is in any way harmful?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 10:17:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 10:17:11 -0000 Subject: [GHC] #9358: Improve flag description in the user guide Message-ID: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Sections 4.20 (Flag reference) and 4.10.2 (-f*: platform-independent flags) of the User Guide could use some updating: - `-floopification` is mentioned in 4.20 but not in 4.10.2 (which, sadly, is my fault), - Section 4.10.2 says: "These flags turn on and off individual optimisations. They are normally set via the -O options (...) The flags below are off by default, except where noted below." Does the last sentence mean they are on by default for `-O` or that they are enabled even with `-O0` (which is the default optimisation level)? - What is the default value of `-fmax-simplifier-iterations`? - 4.20 mentions `-fmax-simplifier-iterations`, `-fmax-relevant-bindings` and `-fmax-worker-args` but only the first one is described in 4.10.2 I suspect there are more inconsistencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 10:34:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 10:34:35 -0000 Subject: [GHC] #9354: AtomicPrimops tests failing on 32-bit x86 in ghci In-Reply-To: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> References: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> Message-ID: <059.a60af0c3485cebd6e854acd2f4aec9f8@haskell.org> #9354: AtomicPrimops tests failing on 32-bit x86 in ghci -------------------------------------------+--------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by pgj): Okay, I have tested this with today's version, and it disappeared. Looks like it came up because I did not fully rebuild the sources when I tested my patch for #9346. Niklas, could you please also confirm this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 11:33:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 11:33:40 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.f41cd008d4a10f2a19762d3f6ba9150d@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Good points. Would someone be willing to make a patch? Not a difficult task. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 11:45:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 11:45:41 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds Message-ID: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ {-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-} module Fam where data Cmp a where Sup :: Cmp a V :: a -> Cmp a deriving (Show, Eq) data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * data instance CmpInterval (V c) Sup = Starting c deriving( Show ) }}} GHC 7.8.3 gives {{{ Fam.hs:12:13: Can't make a derived instance of ?Show (CmpInterval ('V c) 'Sup)?: No family instance for ?CmpInterval ('V c) 'Sup? In the data instance declaration for ?CmpInterval? }}} which is obviously wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 11:46:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 11:46:44 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.5391b1ebd152372ede74daea1349fafe@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > {-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-} > module Fam where > > data Cmp a where > Sup :: Cmp a > V :: a -> Cmp a > deriving (Show, Eq) > > data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * > data instance CmpInterval (V c) Sup = Starting c > deriving( Show ) > }}} > GHC 7.8.3 gives > {{{ > Fam.hs:12:13: > Can't make a derived instance of ?Show (CmpInterval ('V c) 'Sup)?: > No family instance for ?CmpInterval ('V c) 'Sup? > In the data instance declaration for ?CmpInterval? > }}} > which is obviously wrong. New description: Consider {{{ {-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-} module Fam where data Cmp a where Sup :: Cmp a V :: a -> Cmp a deriving (Show, Eq) data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * data instance CmpInterval (V c) Sup = Starting c deriving( Show ) }}} GHC 7.8.3 gives {{{ Fam.hs:12:13: Can't make a derived instance of ?Show (CmpInterval ('V c) 'Sup)?: No family instance for ?CmpInterval ('V c) 'Sup? In the data instance declaration for ?CmpInterval? }}} which is obviously wrong. Reported on [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-July/025145.html glasgow-haskell-users]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:04:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:04:23 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.505183e3da454add5f6378d6a54bc2cb@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T9359 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: cheater00@? (added) * testcase: => deriving/should_compile/T9359 Comment: Great bug report, thank you. For good reasons, processing the `deriving` clause is well separated from other processing of the `data instance` declaration. Making kind arguments explicit, the latter gives {{{ data instance CmpInterval * (V (c::*)) Sup = Starting c }}} that is, this only applies at kind `*`, because the RHS says that `c::*`. But when processing the `deriving` clause we were forgetting to kind-check the RHS, so we were trying to derive an instance for `Show (CmpInterval k (V (c::k)) Sup`; and indeed there isn't one. Fix coming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:12:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:12:42 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.8a6d3c13fcf6d65d6ba979d8fcf3af7e@haskell.org> #9349: excessive inlining with -fpre-inlining -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by klao): Here's a simplified example for this bug: {{{ import Control.Monad import Control.Concurrent.MVar expensive :: Int -> Int -> Int expensive n0 a = go n0 a where go 0 x = x go n x = go (n-1) ((x * 37 + 1973) `rem` 177) main :: IO () main = do mv <- newMVar (10 :: Int) let ex = expensive 100000 3 replicateM_ 30000 $ do x <- readMVar mv print $ x + ex }}} You could probably simplify it further. The important thing is that `ex` is the result of some expensive computation that incorrectly gets evaluated over and over again. And you have to put some "real" IO into the `replicateM_` for the bug to kick in (in the original example it was reading from the stdin, here I just read an MVar). Unlike the original example, here marking `ex` as `NOINLINE` does make the issue disappear. (Otherwise it's the same as the original example: nearly instantaneous with `-O0` or `-O -fno-pre-inlining`, but takes a looong time with `-O`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:38:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:38:59 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.332348390ec1ee3ae4cac58c8050805d@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I was finally able to figure out how to read that file, and wow. Those are some impressive results. Of course the allocation and destruction of the `Queue` is not for free. Just to make sure I didn?t do anything stupid: Can you reproduce my results? If we are worried about `seq` we can simply inline my `myScanl'` in `initsQ2` and replace the `seq` by `case` statements. Or leave the `seq` but argue that we are always applying them to values of type `Queue`, nothing breaks. And by that argument, as long as `myScanl` is only used for `initsQ2`, we should be safe. I guess we only should worry about actually adding `scanl'` to the libraries, but that?s a different issue and should be discussed in #9356 I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:46:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:46:56 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.9fe24dec6c5dee7e7ec9aa8e7538724c@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: T9156 | Blocking: | Differential Revisions: Phab:D87 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d2942184c8cc53cb3b50f78a7ecff930c3e5861f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d2942184c8cc53cb3b50f78a7ecff930c3e5861f" Fixed issue with detection of duplicate record fields Duplicate record fields would not be detected when given a type with multiple data constructors, and the first data constructor had a record field r1 and any consecutive data constructors had multiple fields named r1. This fixes #9156 and was reviewed in https://phabricator.haskell.org/D87 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:48:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:48:23 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.b30af8ea83b0bf42a9b04b983fea71b9@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: T9156 | Blocking: | Differential Revisions: Phab:D87 | -------------------------------------+------------------------------------- Comment (by nomeata): Applied. Sorry, Gintautas, for the delay and thanks for your second contribution to GHC! I hope there will be more to come :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:48:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:48:29 -0000 Subject: [GHC] #9156: Duplicate record field In-Reply-To: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> References: <048.af4078ff0420b879f4627d653fedd20f@haskell.org> Message-ID: <063.20b4828fb876c08c17e9db8b7d21b913@haskell.org> #9156: Duplicate record field -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: gintas Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: T9156 | Blocking: | Differential Revisions: Phab:D87 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 12:49:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 12:49:35 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.9cdc68f2a542834db2e46002aaf51979@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | nofib/spectral/calendar | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): See #9349 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 13:33:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 13:33:41 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.84a7f364da0976e6fdd4d544e91f3dde@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I just checked the source code and `-fmax-simplifier-iterations` default value is 4. Using `-Odph` bumps it to 20. Another issue: - Both 4.20 and 4.20.1 mention the incorrect `-fmax-relevant-bindings` flag name. The correct is `-fmax-relevant-binds` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 14:46:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 14:46:21 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs Message-ID: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell. {{{ $ ghc -e '2 + 2' 4 }}} One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it. {{{ ghci -e '2 + 2' ghc: on the commandline: cannot use `--interactive' with `-e' Usage: For basic information, try the `--help' option. }}} I think this behavior is quite unintuitive--when I pass `-e ` to ghci, or pass `--interactive -e ` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 14:57:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 14:57:54 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.4cd9af2e213346476be484b56efb3ccc@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T9359 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6ce708c916e2f14a58a4ee2b865bc9026a68d611/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ce708c916e2f14a58a4ee2b865bc9026a68d611" Use the right kinds on the LHS in 'deriving' clauses This patch fixes Trac #9359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 15:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 15:01:29 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.f6ad86885412f7dc242c1a6bcf011316@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T9359 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Merge to 7.8.4 if we ever release such a thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 15:13:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 15:13:33 -0000 Subject: [GHC] #9361: 'Cant do annotations without GHCi' when compiling 'Data.Vector.Fusion.Stream.Monadic' for Pandoc in Ubuntu 14.04 on ARMv7 Message-ID: <047.051d3da0dacf7ac386c8caa8e6e6dacc@haskell.org> #9361: 'Cant do annotations without GHCi' when compiling 'Data.Vector.Fusion.Stream.Monadic' for Pandoc in Ubuntu 14.04 on ARMv7 ----------------------------+--------------------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------- Trying to install Pandoc as a dependency for RStudio in Ubuntu using ARMv7 arch (Chromebook). Installed GHC using apt-get, then cabal from the source code. Updated cabal and ran $ cabal install pandoc. Quite sure this worked successfully last week but now getting: [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d r7Jr} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 15:38:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 15:38:31 -0000 Subject: [GHC] #9361: 'Cant do annotations without GHCi' when compiling 'Data.Vector.Fusion.Stream.Monadic' for Pandoc in Ubuntu 14.04 on ARMv7 In-Reply-To: <047.051d3da0dacf7ac386c8caa8e6e6dacc@haskell.org> References: <047.051d3da0dacf7ac386c8caa8e6e6dacc@haskell.org> Message-ID: <062.6311e31e9d74a158e7181317b789378b@haskell.org> #9361: 'Cant do annotations without GHCi' when compiling 'Data.Vector.Fusion.Stream.Monadic' for Pandoc in Ubuntu 14.04 on ARMv7 ---------------------------------------+--------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------- Changes (by carter): * status: new => closed * version: 7.8.2 => 7.6.3 * resolution: => duplicate Comment: I believe this is resolved if you use ghc 7.8. Could you try doing this who ghc 7.8 rather than 7.6? The issue is that prior to 7.8, once of the pragmas that let's you do the spec constr optimization required ghci. This restriction is lifted in 7.8 I'm marking it as a duplicate, but could you please verify that your problem is resolved by using ghc 7.8? You may have to use a ghc build that doesn't come with your distro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 19:46:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 19:46:30 -0000 Subject: [GHC] #9116: RTS Linker doesn't recognize .text.unlikely section on Windows In-Reply-To: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> References: <046.5c0df74d4f5647bfd1a9764670611eb2@haskell.org> Message-ID: <061.db7d4908b8a74594faedd7f871d0b4e3@haskell.org> #9116: RTS Linker doesn't recognize .text.unlikely section on Windows -------------------------------------+------------------------------------- Reporter: niklasl | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: GHC | hour) rejects valid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by niklasl): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 19:51:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 19:51:30 -0000 Subject: [GHC] #9362: make clean deletes inplace mingw Message-ID: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> #9362: make clean deletes inplace mingw -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Running `make clean` removes the mingw toolchain from the inplace directory, forcing another `configure` before building is possible again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 20:03:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 20:03:56 -0000 Subject: [GHC] #9362: make clean deletes inplace mingw In-Reply-To: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> References: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> Message-ID: <061.af5d6c34d25ad2d0b3fac8a07ee7d52c@haskell.org> #9362: make clean deletes inplace mingw -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by niklasl): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 20:32:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 20:32:35 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.aef3fd649ec48d2c5e0e003b9fa7ccac@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:13 nomeata]: > If we are worried about `seq` we can simply inline my `myScanl'` in `initsQ2` and replace the `seq` by `case` statements. Or leave the `seq` but argue that we are always applying them to values of type `Queue`, nothing breaks. And by that argument, as long as `myScanl` is only used for `initsQ2`, we should be safe. I believe I have now pretty much completed the proof. It's very ugly, because I don't have a sufficiently firm understanding of the higher-order fold involved, but here's the outline (minus horrors of immature mathematics): {{{ foldr evil wrong (scanl' f a bs) = foldr evil wrong $ a `seq` a : foldr (\b g x -> let b' = f x b in b' `seq` (b` : g b')) (\b -> b `seq` []) bs a -- Call this e1 a bs =?= (\c n -> a `seq` a `c` foldr (\b g x -> let b' = f x b in b' `seq` (b' `c` g b')) (\b -> b `seq` n) bs a) evil wrong -- Call this e2 a bs }}} There are two trivial base cases: {{{#!haskell e1 [] = e2 [] = evil a wrong e1 _|_ = e2 _|_ = evil a _|_ }}} Then the part I found difficult was proving that {{{#!haskell e1 a (q:bs) = evil a $ let b1' = f a q in b1' `seq` e1 b1' bs }}} to match the much simpler {{{#!haskell e2 a (q:bs) = evil a $ let b1' = f a q in b1' `seq` e2 b1' bs }}} For the infinite case, I don't know the formalism involved, but the general idea is that `evil` can only inspect a finite amount of its second argument before producing something, so we can always (temporarily) cut off the list somewhere past that. > I guess we only should worry about actually adding `scanl'` to the libraries, but that?s a different issue and should be discussed in #9356 I guess. Yes, but I now think we should. > We could also write `initsQ` in the completely inlined form, i.e. the core above. Plus point: No need to define the `Queue` datatype (which would be dead code anyways). Minus point: Doesn?t look elegant, no fusion possible. It doesn't look bad at all, but I think it's pretty much write-only code?it's hard to see what it's doing and why, and hard to experiment with as we've been doing (swapping modular pieces around to try different things). Giving up possible fusion to attain less clarity does not look like a good plan to me. I'm going to do some benchmarking and profiling myself; I'd like to toss a fusable non-strict scanl into the ring for comparison, and ramp up the scale on some of the benchmarks to improve resolution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 20:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 20:44:23 -0000 Subject: [GHC] #9356: scanl does not participate in stream fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.ab5251e23188f47f6a02b31a638af600@haskell.org> #9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 7.8.2 => 7.8.3 Old description: > nomeata came up with a fusing version of a strict `scanl'` in a comment > on #9345. It's not entirely clear to me whether that's entirely safe, but > a non-strict version of it for `scanl` would be, as both a good producer > and good consumer, presumably made efficient using the same sorts of > magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to > write as a good consumer; only the production side remains to be proved. New description: nomeata came up with a fusable version of a strict `scanl'` in a comment on #9345 that uses the same basic technique as the new `foldl`. I think we should use something like the following non-strict version to replace the current `scanl`: {{{#!haskell scanl :: (b -> a -> b) -> b -> [a] -> [b] scanl f a bs = build $ \c n -> a `c` foldr (\b g x -> let b' = f x b in (b' `c` g b')) (const n) bs a }}} While we're at it, we should make sure that `map g . scanl f a` and `scanl f a . map g` fuse properly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 20:53:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 20:53:27 -0000 Subject: [GHC] #9354: AtomicPrimops tests failing on 32-bit x86 in ghci In-Reply-To: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> References: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> Message-ID: <059.13c01118ceea09cae654be6ae18c65ed@haskell.org> #9354: AtomicPrimops tests failing on 32-bit x86 in ghci -------------------------------------------+--------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by niklasl): Everything passes for me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 21:06:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 21:06:09 -0000 Subject: [GHC] #9363: windows configure 'find invalid mode' Message-ID: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> #9363: windows configure 'find invalid mode' -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- When running `configure` on Windows several tests fail with `/usr/bin/find: invalid mode '+111'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 21:09:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 21:09:35 -0000 Subject: [GHC] #9363: windows configure 'find invalid mode' In-Reply-To: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> References: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> Message-ID: <061.76fc48aeb0bad55c2c0ead568d9f3646@haskell.org> #9363: windows configure 'find invalid mode' -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by niklasl): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 21:48:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 21:48:35 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.0ec04a989f1f35c2987bdabc01e87353@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Do you mean that the expression should be evaluated, the result printed, and then you?d end up at the GHCi prompt? I would rather expect `ghci -e` to simply behave like `ghc -e`. Note that python and perl will either evaluate an expression from the command line *or* give you the REPL loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 22:04:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 22:04:16 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.5fcb58dd1ce71b1b1757eb0bf7af4165@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): On Tuesday I promised Richard I'd write up the two variations of our proposed consensus, on the [wiki:GhcKinds/KindInference wiki page]. I have now done so. A couple of questions labelled '''Simon''' are in the text. Over to Richard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 22:09:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 22:09:33 -0000 Subject: [GHC] #9151: Recursive default associated types don't kind-generalize properly In-Reply-To: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> References: <047.9dea5f44f3c45bff10f88ce9afec329a@haskell.org> Message-ID: <062.d9388137386e644c6d69e7b0be4cae73@haskell.org> #9151: Recursive default associated types don't kind-generalize properly -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm reluctant to change the way that associated type defaults are kind- checked; but solving #9200 will also allow this program to be kind- checked. `ToEnum` will be treated as having a CUSK, and hence will support polymorphic recursion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 22:09:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 22:09:55 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.fa421c4868f1b4551e840cbb6e625e38@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #9151 which will be nailed by this change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 22:11:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 22:11:41 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.97c5529b4e16732a12cfb153cca1f5c3@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mcandre): Either of two behaviors would be great: * Just the expression evaluates, prints, and the user is returned to the terminal shell prompt. * The expression becomes the first thing run and printed in a normal ghci session. I don't mind which of these happens, as long as ghc does one of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 22:36:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 22:36:17 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.c991cb4432c3bf9436c4b903a857443e@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): OK, so it didn't turn out to be quite as trivial as I thought, but it looks like this does the trick: {{{#!haskell scanr :: forall a b . (a -> b -> b) -> b -> [a] -> [b] scanr f q0 ls = build scr where scr :: forall c . (b -> c -> c) -> c -> c scr c n = snd $ foldr go (q0, q0 `c` n) ls where go x (r,est) = let fxr = f x r in (fxr, fxr `c` est) }}} Fortunately, the tuples get unboxed as they should. Some extra rules may be needed for map, et al. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 24 23:35:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jul 2014 23:35:38 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.5f82b0dde0fa34a98cd9ac24ad8f892d@haskell.org> #9349: excessive inlining with -fpre-inlining -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): First, I believe that `-fno-state-hack` would be better than `-fno-pre- inlining`, because it's less drastic. You might want to check that it does indeed cure the problem. I understand why NOINLINE is not working. The work is being duplicated by float-in, not by inlining! Consider {{{ let {-# NOINLINE rangeMap #-} rangeMap = expensive in replicateM_ n (\s -> ...rangeMap...) }}} The float-in pass picks up let-bindings and floats them inward as far as possible, but not inside a lambda (unless it's a one-shot lambda). So float-in does this: {{{ replicateM n (\s -> ....(let rangeMap = expensive in rangeMap)...) ... }}} The real culprit is, of course that the `\s` isn't one-shot. But that's why NOINLINE doesn't help. I suppose we could say that float-in should not move a NOINLINE binding; or at least should not move it in past a lambda, whether one-shot or not. I suppose that might be a finer-grained way of allowing you to fix the thing, a little less brutal than `-fno-state-hack`. The other thing that occurs to me is that for this `\s` we can ''see'' (via cardinality analysis) that it is called more than once. So maybe that can override the state-hack nonsense. Needs more looking at. Anyway I thought I'd write down what is going on. Is this a show-stopper for anyone? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 03:29:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 03:29:35 -0000 Subject: [GHC] #9364: The Best Bodybuilding Equipment To Own Message-ID: <053.3db459cf3ccdc3598733fe55300e6507@haskell.org> #9364: The Best Bodybuilding Equipment To Own -------------------------------------+------------------------------------- Reporter: peterdivison25 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- musclebuilding became a hysteria because of a man in the show Pumping Shackle featuring, you guessed it, Traitor Schwarzenegger. Before jumping into bodybuilding, the freshman maneuver is creating goals of where you essential to be and on what period enclose you need to get there. [http://testcoreprofacts.com/ Testcore Pro] Do you require to form rowdy prayer or is your goal to get incline by toning up?More factors ascertain the typewrite of equipment you use in your interior or the gym. The fortitude of the musclebuilding turn is developing strength accumulation. Pairs of liberal weights, which are also the most effectual equipment for exercise, are the slightest costly. The ability to be takeout, future in a panoramic difference of designs and readily acquirable piddle them a hot vendor. Progressive your coefficient extent easy over indication implementation only purchasing the unfixed weights as you require them. They can be adapted to your actual workout Workout is extremely taxing and fix must be embezzled to abstain trauma and emphasise on '''Testcore Pro''' the muscles. Whether you are a paid or right starting out, you moldiness recall to cyclic and supplement your workout subprogram with the sufficient nutrition and quietus. Also, your body needs to reside between workouts, modify though you may essential to use out every day. Learn the schedule and intensities.Depending on your fitness steady, aim for one to phoebe sensible workouts per week and gradually growth the magnitude and continuance of your workouts. Employed diametrical groups of muscles on assorted life will earmark apiece radical to loosen over example.If your content does not include the efinition of a athlete muscleman, dumbbells are the unsurpassable equipment to use. If the pool is winsome to you, flora dumbbells are acquirable too. This is high for group with gage problems and arthritis. Both of these are soft and portable. http://testcoreprofacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 04:08:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 04:08:31 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.f6de2b508478a5cc524231643575eab9@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): OK here's the situation. Kazu's program is statically linked against the GHC API (ghc builds statically-linked executables by default) which means GHC is loading the static library versions of ghc-prim, integer-gmp, base. This was the case in GHC 7.6 also, but that version shipped with .o files (e.g. HSghc-prim-0.3.0.0.o) which the GHC linker can read as a single unit. These are not included with GHC 7.8 on platforms that use dynamic libraries by default (I guess since GHCi would not use them), so GHC 7.8 has to read the .a files instead. As described in a comment in `loadArchive()`, for reasons having to do with alignment, each member object file of an archive is loaded into its own mmap()ed page(s). The base package consists of approximately a zillion tiny object files (split objects), each of which costs 4 kilobytes, so as the comment mentions, this is quite wasteful. Almost all of the memory mapped by the program under 7.8 is attributable to either these mappings or to the executable file itself. We could perhaps come up with a more efficient scheme for loading archive files, but a workaround is to just build the executable with `-dynamic`, so that it will load the GHC API as a shared library and avoid this excessive allocation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 04:47:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 04:47:25 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.9dcfd413da087e32f864ede5fd38c3aa@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): I confirmed that -dynamic reduces the memory usage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 04:49:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 04:49:39 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.68b2e3537f046a230a11a2db3c590c3b@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #8213 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: dfeuer => Comment: Not sure I know enough about the depths of this part of the system to own the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 05:30:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 05:30:35 -0000 Subject: [GHC] #9365: Bodybuilding And Overcoming Daily Workout Fatigue Message-ID: <053.cebced7cc2dab59d3bcaa6d2c219172e@haskell.org> #9365: Bodybuilding And Overcoming Daily Workout Fatigue -------------------------------------+------------------------------------- Reporter: peterdivison25 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- How can you eff a eager workout without having to see so drooping the inactivity of the day." The lick power assail you.You likely see women and men that are so busy, that the only experience they can workout is at 5:00 in the farewell. Maybe you eff to do that too. I worked out with [http://testcoreprofacts.com/ Testcore Pro] several of these fill and launch out what they do for a experience and why they're employed out so inchoate.Turns out that they are doctors, lawyers, sports therapists, cerebration workers, certificate guards, parents, one was smooth a US Representative. They all relish excavation out, but individual mentioned almost opinion fatigued the intact day (after having a near workout).So I set out to conceptualize an fulfill to this problem.More of these fill were winning protein supplementation. It's high for helping you to be unagitated, but can pay to the perception of beingness beat. Variety of suchlike the "asleep" somaesthesia after having a colossal nutriment. But with a goodness workout, you truly get to be taking protein to full sell the benefits of these "severe" workouts.I also saved that umpteen of these group weren't effort sufficiency nap. They were serendipitous to get 7-8 hours of sleep, though few claimed only 5-6 hours at most, as the repose of their lives were really '''Testcore Pro''' diligent hence the reason for archean morning workouts. So symmetric fair adding an period of sleep each nighttime, if getable, can rattling supply.Whatsoever of these people were uptake workout drinks with caffeine. Piece this is enthusiastic to get in the start, the substance cause can be a whacked somesthesia the relief of the day, unless they crapulence any solon caffeine which can then donjon one from beingness healthy to go to bed that dark to get sufficiency quietus. http://testcoreprofacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 05:57:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 05:57:58 -0000 Subject: [GHC] #9354: AtomicPrimops tests failing on 32-bit x86 in ghci In-Reply-To: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> References: <044.5db64b55ffbcd2f0ee4bbc831520bcd5@haskell.org> Message-ID: <059.64ab917d5d7b6bf1a350455f53a238ad@haskell.org> #9354: AtomicPrimops tests failing on 32-bit x86 in ghci -------------------------------------------+--------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Changes (by tibbe): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 06:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 06:02:34 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.43fb85ecfc279a2bb676f467dfe8a86b@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I agree that there's no reason why one version of the compiler should produce the same ordered list as the next version, but isn't it a bit odd that the stage1 and stage2 builds of the same compiler would give different output? That suggests a change in semantics of a function in base or something of that sort, doesn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 06:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 06:24:55 -0000 Subject: [GHC] #5924: Bad Cmm generated for updating one element in Array# In-Reply-To: <044.f3ab1cc0e2323fdeb60fa68254394154@haskell.org> References: <044.f3ab1cc0e2323fdeb60fa68254394154@haskell.org> Message-ID: <059.63276c8c7a53ffab0eb38952e65ac2ca@haskell.org> #5924: Bad Cmm generated for updating one element in Array# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: This ticket is a bit too vague to be actionable. Some of the issues here are tracked elsewhere and some have already been fixed (like inline allocation of small, fixed size arrays.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 06:27:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 06:27:55 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.d1ee58e251f1a79b6e4f907f5f80405f@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 06:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 06:29:28 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.c61c774b610d4efc1d11c8fd90962078@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8667 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * cc: hvr (added) Comment: This is now correctly documented at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingaGHCrepositoryfromGitHub. Do we also want to keep this info in the README? If so we should fix the docs there too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 06:51:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 06:51:04 -0000 Subject: [GHC] #9314: Huge space leak of GHC API 7.8.x In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.c105b4010df521f4fea073a289411077@haskell.org> #9314: Huge space leak of GHC API 7.8.x -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid, thank you. I have no opinion about dynamic linking (except that it is generally the work of the devil, and has caused us a totally unreasonable amount of pain), but we should all be very grateful to you for diagnosing what is going on. I would never have thought of that in a million (or zillion) years. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 07:26:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 07:26:34 -0000 Subject: [GHC] #9366: 13 Fitness Tips To Stay Motivated And Workout Effectively Message-ID: <053.9c86987813e787539a7d97308a8b5eb4@haskell.org> #9366: 13 Fitness Tips To Stay Motivated And Workout Effectively -------------------------------------+------------------------------------- Reporter: peterdivison25 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Record fitness magazines. Suitableness magazines are a zealous communicator of both accumulation and aspiration. They can ameliorate remind you of why you poorness to get fit in the best position! [http://testcoreprofacts.com/ Testcore Pro] Output out with a person. Not only can this meliorate you actually get to your workout human, but friends can supply encourage each different to pass out with writer intensity.Set a systematic abstraction for condition. If you somebody shape moment unified into your schedule, it's such easier to force with it, especially over minute.Grow exertion activities that you relish. Whilst it's alpha to fuck a counterbalanced workout, there are numerous slipway to body bully and posture, flexibleness, and get aerophilic utilize. Database the types of activities you savor, or consider you strength savor, and start excavation finished all of them. You could flatbottomed rotate them every 6 weeks.Physique show into your thought. Not exclusive does this change it many absorbing, you'll actually line variant sinew groups, or the unvaried muscles but in a polar way. The challenges we create for our body in adapting to new types of '''Testcore Pro''' exercises results in a fitter and stronger body. Alter your info every 6 weeks.Try new suitability activities - Try diversion, enclosure, plates, yoga, or kickboxing.Underframe the intellection of effort in a electropositive way in your psyche. Flatbottomed if you don't same take, try and reckon of it in a optimistic way - that way you are fewer promising to reveal yourself out of it. Cogitate of how favourable you undergo afterwards, not the somatesthesia interested in exploit there!Read outdoors. Whether it's unit sports or aquatics, get out in the unsoured air!Try skipping. Skipping ropes fit into bittie bags, don't order valuable gym memberships, are gettable for use 24 hours a day, are never overcrowded, and are major aerophilic activity.Try condition breeding. Status preparation module gain the situation and magnitude of your muscles, thus preventing injuries. If you're not up to aweigh weights, screw a journey categorize, or a bodypump grade. http://testcoreprofacts.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 07:39:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 07:39:43 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.a9e120ac8699a339bbf1a87250b054f7@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: simonmar, simonpj (added) Comment: I've cc'ed you both to trigger any comments you might have with respect to the results from comment:1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 08:41:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 08:41:01 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.132532687bed7e5119bfec30789d64ed@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > (because the argument to build isn't allowed to inspect its own result as the implementation in Data.List does), I wouldn?t be surprised that returning `(# x, x:xs #)` is faster than returning `x:xs` and pattern matching on it. OTOH, the CPR optimization should change the code returning `x:xs` into (# x, xs #) and move the consing to the caller. Can?t you do that by hand, i.e.: {{{ scanrB :: forall a b . (a -> b -> b) -> b -> [a] -> [b] scanrB f q0 ls = build scr where scr :: forall c . (b -> c -> c) -> c -> c scr c n = case foldr go (q0, n) ls of (r, esult) -> c r esult where go x (r,est) = (f x r, r `c` est) }}} The Core looks a bit nicer: {{{ Scanr.scanrA :: forall a b. (a -> b -> b) -> b -> [a] -> [b] Scanr.scanrA = \ (@ a) (@ b) (f :: a -> b -> b) (q0 :: b) (ls :: [a]) -> let { a :: [b] a = GHC.Types.: q0 (GHC.Types.[]) } in letrec { $wgo :: [a] -> (# b, [b] #) $wgo = \ (w :: [a]) -> case w of _ { [] -> (# q0, a #); : y ys -> case $wgo ys of _ { (# ww1, ww2 #) -> let { fxr :: b fxr = f y ww1 } in (# fxr, GHC.Types.: fxr ww2 #) } }; } in case $wgo ls of _ { (# _, ww2 #) -> ww2 } Scanr.scanrB :: forall a b. (a -> b -> b) -> b -> [a] -> [b] Scanr.scanrB = \ (@ a) (@ b) (f :: a -> b -> b) (q0 :: b) (ls :: [a]) -> letrec { $wgo :: [a] -> (# b, [b] #) $wgo = \ (w :: [a]) -> case w of _ { [] -> (# q0, GHC.Types.[] #); : y ys -> case $wgo ys of _ { (# ww1, ww2 #) -> (# f y ww1, GHC.Types.: ww1 ww2 #) } }; } in case $wgo ls of _ { (# ww1, ww2 #) -> GHC.Types.: ww1 ww2 } }}} But I don?t expect there to be a measurable difference (and I didn?t check): > Some extra rules may be needed for map, et al. not sure what you mean by that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 09:03:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 09:03:47 -0000 Subject: [GHC] #9349: excessive inlining with -fpre-inlining In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.dc078daad76b176c1aac552d05f5a0bc@haskell.org> #9349: excessive inlining with -fpre-inlining -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by klao): I can confirm that `-fno-state-hack` does cure the problem; both in the original example and my simplified test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 09:22:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 09:22:04 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.977b87ea4f689816ddba9d34913a502e@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8667 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:8 tibbe]: > This is now correctly documented at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingaGHCrepositoryfromGitHub. Do we also want to keep this info in the README? If so we should fix the docs there too. I guess so, as one of the major uses of the GitHub mirror is if `git.haskell.org` is down (in which case the GHC Wiki is probably down too) for some reason. Then you'd want to have some instructions that can be found easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 09:29:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 09:29:51 -0000 Subject: [GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments In-Reply-To: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> References: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> Message-ID: <062.a0f5e0a1c58fe8fd3e35503ca6ba6a51@haskell.org> #9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a997f2df785448648e7137a88d6b38eeb2643aa1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a997f2df785448648e7137a88d6b38eeb2643aa1" Check for boxed tau types in the LHS of type family instances Fixes Trac #9357 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 09:37:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 09:37:30 -0000 Subject: [GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments In-Reply-To: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> References: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> Message-ID: <062.b0d43e738a772fab8b7d0c61f14426ac@haskell.org> #9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point. It's not impossible that we could accept unboxed ''arguments'' to type families, but unbozed ''results'' would definitely be problematic: how many bits does it take to represent `(F Int)`? Is is held in an integer register or a floating point register. For now I've just made it so that we require a boxed monotype as both argument and result. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 09:37:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 09:37:42 -0000 Subject: [GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments In-Reply-To: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> References: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> Message-ID: <062.6b2f24040f347852109c7d3321a602f4@haskell.org> #9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 10:17:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 10:17:28 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.e2b412332c9e701e1de6019176b9f586@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so here's the patch I'm guessing you tried {{{ Modified compiler/typecheck/TcType.lhs diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index a952ce7..d643f6e 100644 --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -1556,10 +1556,11 @@ marshalableTyCon :: DynFlags -> TyCon -> Bool marshalableTyCon dflags tc = (xopt Opt_UnliftedFFITypes dflags && isUnLiftedTyCon tc - && not (isUnboxedTupleTyCon tc) - && case tyConPrimRep tc of -- Note [Marshalling VoidRep] - VoidRep -> False - _ -> True) +-- && not (isUnboxedTupleTyCon tc) +-- && case tyConPrimRep tc of -- Note [Marshalling VoidRep] +-- VoidRep -> False +-- _ -> True + ) || boxedMarshalableTyCon tc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 10:22:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 10:22:21 -0000 Subject: [GHC] #9359: Deriving clause failure with polymorphic kinds In-Reply-To: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> References: <046.75650ae2479229e1e2c9c7cf11a3c497@haskell.org> Message-ID: <061.e012dda346973b11f278c1f76209d800@haskell.org> #9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T9359 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cheater): * cc: cheater00@? (removed) * cc: cheater (added) Comment: Thank you very much, this is why GHC is so great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 10:27:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 10:27:41 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.514fcb02d8a4dade27e95371573a2874@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Simon M: looking into the code, I'm quite perplexed. Have a look at: DsCCall.boxResult. It seems the when we say {{{ foreign import foo :: Int -> Int }}} we actually generate (in effect) an inline use of `unsafePerformIO`. Here's the tidy core: {{{ M.foo :: GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType] M.foo = \ (ds_d1A2 :: GHC.Types.Int) -> case ds_d1A2 of _ [Occ=Dead] { GHC.Types.I# ds2_d1A4 -> case {__pkg_ccall main foo Int# -> State# RealWorld -> (# State# RealWorld, Int# #)}_d1A7 ds2_d1A4 GHC.Prim.realWorld# of _ [Occ=Dead] { (# ds3_d1A6, ds4_d1A5 #) -> GHC.Types.I# ds4_d1A5 } } }}} Note that we come up with a `realWorld#` out of thin air and then discard it again... that's the `unsafePerformIO` stuff. Then the code generator has to painstakingly discard all that state-passing nonsense, to get back to a simple C call to "foo". Why do we bother with this? Why not produce this core: {{{ M.foo :: GHC.Types.Int -> GHC.Types.Int M.foo = \ (ds_d1A2 :: GHC.Types.Int) -> case ds_d1A2 of _ [Occ=Dead] { GHC.Types.I# ds2_d1A4 -> case {__pkg_ccall main foo Int# -> Int#}_d1A7 ds2_d1A4 of ds4_d1A5 [Occ=Dead] { DEFAULT -> GHC.Types.I# ds4_d1A5 } } }}} Simpler, more direct, and should generate exactly the same code. At the moment the built-in `FCallId` Ids always have an IO-ish type, but I see no reason to require that. If we did this, then I think the distinction between `boxResult` and `resultWrapper` could disappear, leading to a simpler, compositional structur. Moreover, if we want to accommodate {{{ foreign import foo :: Int -> State# s -> (# State# s, Int #) }}} which doesn't have an IO-ish type (at least not built with the `IO` type constructor), it would seem utterly bizarre to enclose it in the `unsafePerformIO` boilerplate as above. I think Herbert might be able to act on all this, but first let's check that I have not forgotten anything stupid. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:05:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:05:00 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters Message-ID: <046.188450f148764a8992314b4689d05445@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: linux, terminal, | Operating System: colour, color, prompt | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Hi, there's an issue in the GHCi prompt. To reproduce: 1. Do everything in Linux (I don't have other operating systems); I'm using a version of the gnome 2 gnome-terminal. 2. Use the following to colourise the prompt in GHCi: echo -e :set prompt '"\033[32;1m%s\033[34;1m>\033[0m "' >> ~/.ghc/ghci.conf 3. Import quite a few modules (say, 5 to 10 should be enough) 4. Give the prompt enough text that it wraps around. It's best if you start the text with -- so that it's a comment and doesn't produce any output. For example, say I entered "-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", I now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (do note that the first set of b's is located on the same line as the prompt, and the second is located under the prompt) 5. Press Enter. You should now see: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> 6. Press Ctrl-P or the up arrow key to select the previous history item. You will now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 7. Press Ctrl-A or the Home cursor key to go to the beginning of the text entry, and then type X. You will now see the last prompt to be: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbX-- bbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 8. If you press Enter, you will find out that prompt was actually (without line breaks): X-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb I tried resizing the terminal window to 45 chars to make the lines above shorter; I imported Data.Monoid and Data.Functor in a new GHCi. The prompt contained garbage, most likely badly wrapped escape codes. See attachment. As both likely are a single bug in disguise, I include both reports in this ticket. Creating a test case for whether things actually work in a terminal might be difficult, but creating test for whether things get wrapped correctly (and not testing how things work out in a terminal) should be simple if annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:06:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:06:26 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.e6d2a94e47e0fafc355b806ab9e906d9@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, terminal, Operating System: | colour, color, prompt Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cheater): * cc: cheater (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:25:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:25:07 -0000 Subject: [GHC] #9365: Make command key in GHCi configurable Message-ID: <046.32a9cfe7b1bdb50e0a1f34ea72a75233@haskell.org> #9365: Make command key in GHCi configurable -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hi, GHCi rightly uses the Vim-style mode of entering commands, where prefixing the prompt with a special character makes it into an entry on a meta-level (i.e. a command to the interpreter shell, not to the interpreter itself). Unfortunately, that character is fixed to be ':'. Many Vim power users hate having to press Shift several times a second and so make ';' that character in Vim. It's a popular tip on the Vim Tips site: http://vim.wikia.com/wiki/Map_semicolon_to_colon and tells you to perform the following settings: nnoremap ; : nnoremap : ; vnoremap ; : vnoremap : ; Having used Vim like this for much over ten years now, it's not even a habit or reflex any more to type the semicolon, therefore (for me at least) it's cumbersome and error prone to type the colon in GHCi. I ask that a new GHCi setting be added, with the following UI: :set command-chars "string" where each character of "string" will start command mode. Multiple (at least two) characters should be available for people switching from their old setting to their new setting. When command mode is started, even if you had done :set command-chars ";" and then have typed ';', the prompt should still start with ':', just like in Vim. This is to signify that you're in the command "mode". Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:32:55 -0000 Subject: [GHC] #9366: Trac stylesheet minor cosmetic issue Message-ID: <046.97b3c1ae2e68483e115bd1524b22e133@haskell.org> #9366: Trac stylesheet minor cosmetic issue -------------------------------------+------------------------------------- Reporter: cheater | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.8.2 Keywords: css, stylesheet, | Operating System: navbar | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Hi, the styling of the navigation bar is somehow weird. It's not a big issue, I just thought it's worth keeping track of. Please see attachment. Tested on Firefox 31 and Chromium 34 with the same effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:37:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:37:03 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.23b920d466165b18938b6cc02cdb2ad7@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, terminal, Operating System: | colour, color, prompt Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5850 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cheater): * related: => 5850 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:38:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:38:52 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.6e1e57fced50c2d56936e351445c88a2@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, terminal, Operating System: | colour, color, prompt Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5850 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cheater): * related: 5850 => #5850 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 11:44:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 11:44:19 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.b48337f3afd8d6bdbc96f1fa27c8c3f0@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Comments on wiki page addressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 12:08:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 12:08:25 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.1619badb61c966c1b56330694627c1f5@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9281 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Fyi, just something I just noticed while implementing a new Cmm primop and the associated `prim` FFI import: The following doesn't work, as GHC doesn't deem `State#` an acceptable return type: {{{#!hs foreign import prim "integer_gmp_cmm_shrink_mba" shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s }}} However, the following works: {{{#!hs foreign import prim "integer_gmp_cmm_shrink_mba" shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 12:25:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 12:25:04 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.6a154a48040a5ebf37b686fc8448bbe9@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Responses from Simion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 15:12:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 15:12:32 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.b6b7d5e26e22fa5b02e4b7ece15145ed@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry Jan I'm struggling with this one. My main difficulty is that I don't understand arrows well enough, and I do not have a stand-alone document giving the typing rules they are supposed to obey, one that matches the syntax and deguaring used in GHC. (There are some changes described above, and I do not know how they fit in either.) What would be really helpful would be a wiki page or Latex document that gave * The syntax for arrows, including a clear indication of how it is represented in !HsSyn * The static semantics as typing rules * The desugaring into Core The second and third of these are connected, because the type checker must generate the evidence that will be used by the desugarer to translate to Core. I believe that the static semantics may be specified (perhaps only in part), as comment:17 suggests, by translation into some simpler combinators. In short, it's a nice, cleanly-separable problem; and has clear intellectual challenge; but I feel unable to contribute much at the moment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 15:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 15:22:47 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.45beb71a3330b5209e08b475af287410@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"92587bfefea2b78f89bcdad27e0da5711463fd1b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="92587bfefea2b78f89bcdad27e0da5711463fd1b" Refactor FFI error messages This patch was provoked by Trac #5610, which I finally got a moment to look at. In the end I added a new data type ErrUtils.Validity, data Validity = IsValid -- Everything is fine | NotValid MsgDoc -- A problem, and some indication of why with some suitable combinators, and used it where appropriate (which touches quite a few modules). The main payoff is that error messages improve for FFI type validation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 15:27:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 15:27:08 -0000 Subject: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message In-Reply-To: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> References: <046.fdf192326307b04dbc38c6023f0d4891@haskell.org> Message-ID: <061.e3c56310e9a7759f53619ae08528feb6@haskell.org> #5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: closed request | Milestone: Priority: high | Version: 7.6.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Incorrect | warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK I have at least improved the error messages, so I'll close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 16:41:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 16:41:19 -0000 Subject: [GHC] #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines Message-ID: <044.22597e1155087b2ec7457131835e824e@haskell.org> #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines ----------------------------------+--------------------------------------- Reporter: kraai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- When I load a file that uses Windows-style newlines in WinGHCi, set a breakpoint, run to that breakpoint, and execute ":list", the carets that should underline the breakpoint expression are instead appended to the line. I'll attach a screenshot and the file I loaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 16:48:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 16:48:27 -0000 Subject: [GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies In-Reply-To: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> References: <047.6b2af23e852e3dacdefeac6524bf6813@haskell.org> Message-ID: <062.0043d91a95c71579912c83d3b14831b5@haskell.org> #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Reason: * We have a given `D (Eq a)` * Flattened to `fsk` (a `CIrredCan`) plus work-list `D (Eq a) ~ fsk`. * The `CIrredCan` fsk is put in the inert set * ...and that flips `No-eqs` to `False` * We solve `D (Eq a) ~ fsk`, getting `fsk ~ Eq a` * That kicks out the `CIrredCan` so it can be substituted * But it is too late! The no-eqs flag has been flipped. Solution: the no-eqs flag should be computed from the final inert set, not the process. Will be fixed by the same fix as #9211 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 16:49:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 16:49:10 -0000 Subject: [GHC] #9211: Untouchable type variable (regression from 7.6) In-Reply-To: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> References: <046.f06cc4b7cfb9a8801b4e8d69697caf70@haskell.org> Message-ID: <061.0d12f7416dfc1cb71a6926a6718a78e4@haskell.org> #9211: Untouchable type variable (regression from 7.6) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Notes from S and D * Level on skols * Orient skol eqs a~b * Level on EqCtList * getUnsolvedInerts also looks for given equalities FROM THIS LEVEL * ?and finds non-let-bound ones Let-bound ones * a~ty, where a is a skol from this level * F tys ~ b, where b is a skol from this level, and b does not appear in any remaining ones (iterate) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 18:41:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 18:41:16 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.08597ad52934c704ffc1aa673b81b38c@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): From ghc-devs: jstolarek: > How can I observe the effects of `-ddump-simpl-phases`? I tried compiling several different programs and this flag seems to have no effect (ie. nothing gets printed). simonpj: > I had to read the source code. ?I think you say >????????"-ddump-simpl-phases=A,B,C" > to dump the output of phases called A,B,C. But no, it seems that it only affects output of simplifier statistics (see simplifyPgmIO). ?I have never used this flag. ?Maybe it can go. ?Looks strange to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 25 21:57:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jul 2014 21:57:21 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List Message-ID: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: #9345 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Joachim Breitner wrote a strictly accumulating fusable `scanl'` in a comment on #9345, and demonstrated that it can produce spectacularly good code. Therefore, it seems like a good thing to have in Data.List. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 01:08:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 01:08:01 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.d10fa11028ce20f52a061d82cda7b5c4@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edward Z. Yang ): In [changeset:"7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349" Module reexports, fixing #8407. The general approach is to add a new field to the package database, reexported-modules, which considered by the module finder as possible module declarations. Unlike declaring stub module files, multiple reexports of the same physical package at the same name do not result in an ambiguous import. Has submodule updates for Cabal and haddock. NB: When a reexport renames a module, that renaming is *not* accessible from inside the package. This is not so much a deliberate design choice as for implementation expediency (reexport resolution happens only when a package is in the package database.) TODO: Error handling when there are duplicate reexports/etc is not very well tested. Signed-off-by: Edward Z. Yang Conflicts: compiler/main/HscTypes.lhs testsuite/.gitignore utils/haddock }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 03:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 03:31:14 -0000 Subject: [GHC] #9369: Female Bodybuilding Message-ID: <056.85b8e136e8b0ffdcc12ae93948338f7b@haskell.org> #9369: Female Bodybuilding -------------------------------------+------------------------------------- Reporter: flaxtermaxemellin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Galore fill hump the misconception that all somebody bodybuilders are musculus treated, hormone sound Amazons, who looking equal General Schwarzenegger. [http://homenspoder.com/ Gmax] There are certainly a littlest containerful of women who instrument fit into this collection and they contend in the elite championships specified as the Ms Plain, notwithstanding the vast figure of women who are attached in bodybuilding are using it purely for toning the body and for suitability.Soul workout is an fantabulous athletics for early women to modify their muscles, hurting fat, and raise their overall suitableness levels so they can compete at a higher even in otherwise sports.By lifting weights women can actually recede body fat, as the yob they are construction needs force, and this is traced from using the vigor that is stored in their embody fat.The ordinary someone human is last to frame enormous muscles without the '''Gmax''' aid of unscheduled supplements or steroids.This is due to the fact that women somebody a low surface of testosterone in their embody and it is testosterone that is needed to frame the tough that men can so pronto advantage.Along with improved muscle step, coefficient lifting also aids in the strength of the courage and the clappers. This is particularly useful because more women worsen from transmutation of their bones in afterwards geezerhood. http://homenspoder.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 05:50:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 05:50:20 -0000 Subject: [GHC] #9370: terine Fibroids Symptoms, Causes and Treatment Message-ID: <056.11e893c40cb8c39c9bcca9bb714f5f55@haskell.org> #9370: terine Fibroids Symptoms, Causes and Treatment -------------------------------------+------------------------------------- Reporter: flaxtermaxemellin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A uterine fibroid is a kind of non-cancerous (benign) tumor that originates in the myometrium muscle layer and adjoining connective tissues in the uterus and can grow[http://homenspoder.com/ Gmax] inside the uterine cavity. Fibroid is the most common form of tumor found in females. It occurs mainly during the middle or later reproductive age in females. Fibroids may grow as a single tumor or in multiple numbers as in clusters. Unlike its name it contains muscles and not fibroid tissues. It occurs in approximately 25% women and can lead to hysterectomy. In United States out of every 5 women over the age of 35, 1 has uterine fibroid. About 60000 hysterectomies are performed annually out of which one-third is a case of uterine fibroid. '''Gmax''' The exact cause for the development of uterine fibroid is still unknown to doctors. However after performing researches they have come up with changes of gene mutation to be cause in the formation of uterine fibroid. But it is still not definite that uterine fibroid could be directly related to genes. Environmental causes can also accentuate the growth. They grow from the smooth muscular tissues and in extreme cases reach even till the rib cage expanding from the uterus. The 2 female hormones necessary for the growth are estrogen and progesterone. A complex interaction between these two hormones accompanied by a number of factors responsible for cell growth causes it, so usually seen in women between the age of twenty five and thirty five. http://homenspoder.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 08:12:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 08:12:22 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.c3a85783544dac7f048053d97035fdf9@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 09:01:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 09:01:10 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.7a561ca84f3860a905efd85a5a947c30@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 09:16:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 09:16:15 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.d58aaf9e5634835fba9c1150b05004e7@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): This fix seems to break the current master build on OS X: {{{ compiler/main/Packages.lhs:867:16: error: unterminated function-like macro invocation where -- ASSERT(m == m' && pkg == pkg' && e == e' ^ compiler/HsVersions.h:39:9: note: macro 'ASSERT' defined here #define ASSERT(e) if debugIsOn && not (e) then (assertPanic __FILE__ __LINE__) else ^ 1 error generated. <> make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 09:31:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 09:31:38 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.ee84cace98639a3fca772e83a4207c4b@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): We really ought to switch to something like `cpphs` (which we can tweak to be better aware of Haskell syntax) for milestone:7.10.1 than having to keep in mind that there's now a 2nd `cpp` out there with slightly different semantics which keeps breaking builds... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 09:41:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 09:41:57 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.bd5db3b287bfc716fdd81b73f98093ec@haskell.org> #8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): I pushed a bandaid fix {{{ commit 9487305393307d5eb34069c5821c11bb98b5ec90 Author: Edward Z. Yang Date: Sat Jul 26 10:41:28 2014 +0100 Fix build on OS X due to macro-like string in comment Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 26 15:33:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jul 2014 15:33:57 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.110a426edc06e3e8a3458b483ce585e4@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by diatchki): I know the code, so I don't mind doing it. Out of curiosity, do you have an example of when you may want to write just `OVERLAPPING` and not `OVERLAPABLE` or vice versa? The way I understand it, they have the following meanings: * `OVERLAPPING` says "I am a most general instance" (i.e., can overlap, but can't be overlapped), * `OVERLAPABLE` says "I am a most specific instance" (i.e., can't overlap, can be overlapped). So, they make some sense for the "edge-case" instances, but not for the ones inbetween, and I couldn't really think of good cases where I may want to put them on an instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 04:28:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 04:28:29 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.d0038a0a5df2fd896afdf45a891c1320@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dmcclean): I second the request for an error message if you quote one. The current behavior had me baffled for a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 05:52:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 05:52:35 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. Message-ID: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue is also serious: inlining `unfoldr` can often allow the `Maybe` to be erased altogether. I'm not sure this fix is perfect, but it seems a lot better than the current situation: {{{#!hs import GHC.Exts (build) {-# NOINLINE [1] unfoldr #-} unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = go b where go b = case f b of Just (a,new_b) -> a : go new_b Nothing -> [] {-# INLINE [0] unfoldrB #-} unfoldrB :: (b -> Maybe (a, b)) -> b -> (a -> c -> c) -> c -> c unfoldrB f b' c n = go b' where go b = case f b of Just (a,new_b) -> a `c` go new_b Nothing -> n {-# RULES "unfoldr" [~1] forall f b . unfoldr f b = build (unfoldrB f b) #-} }}} As a simple example, consider the code {{{#!hs hello :: Double -> Double -> [Double] hello x n = map (* 3) $ L.unfoldr f x where f x | x < n = Just (x, x**1.2) | otherwise = Nothing }}} With `Data.List.unfoldr` and the latest bleeding-edge GHC, this produces {{{#!hs hello1 hello1 = \ ds_d1ZF -> case ds_d1ZF of _ { D# x_a21W -> D# (*## x_a21W 3.0) } $whello $whello = \ w_s266 ww_s26a -> map hello1 (unfoldr (\ x_X1Hx -> case x_X1Hx of wild_a20E { D# x1_a20G -> case tagToEnum# (<## x1_a20G ww_s26a) of _ { False -> Nothing; True -> Just (wild_a20E, D# (**## x1_a20G 1.2)) } }) w_s266) hello hello = \ w_s266 w1_s267 -> case w1_s267 of _ { D# ww1_s26a -> $whello w_s266 ww1_s26a } }}} Using the above implementation (and renaming the function from `hello` to `bye`) yields {{{#!hs $wbye $wbye = \ ww_s25Z ww1_s263 -> letrec { $wgo_s25U $wgo_s25U = \ ww2_s25S -> case tagToEnum# (<## ww2_s25S ww1_s263) of _ { False -> []; True -> : (D# (*## ww2_s25S 3.0)) ($wgo_s25U (**## ww2_s25S 1.2)) }; } in $wgo_s25U ww_s25Z bye bye = \ w_s25V w1_s25W -> case w_s25V of _ { D# ww1_s25Z -> case w1_s25W of _ { D# ww3_s263 -> $wbye ww1_s25Z ww3_s263 } } }}} I don't think there can be any doubt which is better. Yes, some fine tuning may be needed to make the rules apply in all appropriate cases. I don't understand things like the comment on the definition of `map` drawing attention to eta expansion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 06:30:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 06:30:54 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package Message-ID: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I've observed a blowup in ghc memory usage when invoked with parallel build flags. to reproduce {{{ cabal get xmlhtml-0.2.3.2 cabal install xmlhtml-0.2.3.2 --only-dependencies cd xmlhtml-0.2.3.2 }}} then {{{ cabal clean ; cabal configure --ghc-options="-j4" ; time cabal build -j4 -v3 }}} will take quite a while and use > 1gb of ram whereas {{{ cabal clean ; cabal configure --ghc-options="-j1 ; time cabal build -j1 -v3 }}} will use < 150mb of ram. Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 06:36:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 06:36:33 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.5e27dcd681d5db4c7348fcded08cb612@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 08:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 08:00:45 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.b8f50e27333c3446c9343ea4d1cd75cd@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => parmake * failure: None/Unknown => Compile-time performance bug * related: => #910 #9221 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 18:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 18:14:54 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.1dd26a36df1659060557a17b860d7332@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by diatchki): As I started implementing this, it occurred to me that another interpretation of `OVERLAPPING` and `OVERLAPPABLE` is also possible: * `OVERLAPPING`: - may replace ''any'' more general instance; - may be replaced by more specific instances marked with `OVERLAPPING`. * `OVERLAPABLE`: - may be replaced by ''any'' more specific instance; - may replace more general instances marked with `OVERLAPABLE`. This interpretation has the advantage of specifying how to interact with "normal" instances (i.e., ones compiled in modules without special overlapping flags). The drawback is that there is no way for an instance to be sure that it won't be replaced. Perhaps that's OK though---I think the current system does not provide a way to do this anyway. See also #3877 for some related discussuion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 20:51:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 20:51:48 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.bacf05c7a5e598f33e9f84049597ec3f@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by schyler): (By the way, I don't think this counts as a 'Runtime performance bug' as much as it should be categorised as a 'Compile-time performance bug' maybe..) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 21:01:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 21:01:46 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.27930563ebde46b75cf8b60f64699a43@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 schyler]: > (By the way, I don't think this counts as a 'Runtime performance bug' as much as it should be categorised as a 'Compile-time performance bug' maybe..) > > Good work though, +1 from me. My interpretation, correct or not, is that compile-time performance bugs are things that lead to GHC itself running slowly. As long as I'm adding a comment, I'll note that there are functions in the libraries that are very naturally written as unfolds, but that currently are not?perhaps because the current unfold performs so poorly. The ones I've encountered so far are `groupBy` and various implementations of `enumFromTo` that have their own custom rewrite rules to get around this. I can't guarantee anything, but it would be nice to simplify those if we can do so without losing speed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 21:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 21:08:46 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.dddf9b156ad142204851328d119aef6c@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by croyd): Hi, I think I ran in to this issue running the following code (fibonacci matrix exponentiation) in ghci. It seems to happen every single time I execute it inside ghci, but never when using the full compiler (ghc --make). {{{#!hs module Matrix where data Matrix = Matrix Integer Integer Integer Integer deriving (Eq, Show) instance Num Matrix where fromInteger n = Matrix n n n n negate = undefined (+) = plusMatrix (*) = mulMatrix abs (Matrix a00 a01 a10 a11) = Matrix a00' a01' a10' a11' where a00' = abs a00 a01' = abs a01 a10' = abs a10 a11' = abs a11 signum = undefined plusMatrix :: Matrix -> Matrix -> Matrix (Matrix a00 a01 a10 a11) `plusMatrix` (Matrix b00 b01 b10 b11) = Matrix (a00 + b00) (a01 + b01) (a10 + b10) (a11 + b11) mulMatrix :: Matrix -> Matrix -> Matrix (Matrix a00 a01 a10 a11) `mulMatrix` (Matrix b00 b01 b10 b11) = Matrix a00' a01' a10' a11' where a00' = a00 * b00 + a01 * b10 a01' = a00 * b01 + a01 * b11 a10' = a10 * b00 + a11 * b10 a11' = a10 * b10 + a11 * b11 fib4 :: Integer -> Integer fib4 0 = 0 fib4 n = case f ^ n of Matrix _ fn _ _ -> fn where f = Matrix 1 1 1 0 main = do print $ fib4 1000 -- ok putStrLn $ replicate 80 '-' print $ fib4 10000 -- ok putStrLn $ replicate 80 '-' print $ fib4 1000000 -- bus error: 10 }}} crash report: {{{ Process: ghc [30070] Path: /usr/local/lib/ghc-7.8.3/bin/ghc Identifier: ghc Version: ??? Code Type: X86-64 (Native) Parent Process: bash [97679] User ID: 501 Date/Time: 2014-07-27 15:30:12.594 -0500 OS Version: Mac OS X 10.8.4 (12E55) Report Version: 10 Crashed Thread: 1 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000115341000 VM Regions Near 0x115341000: MALLOC metadata 000000011532c000-0000000115341000 [ 84K] rw-/rwx SM=COW --> MALLOC guard page 0000000115341000-0000000115342000 [ 4K] ---/rwx SM=NUL Stack 0000000115342000-0000000115343000 [ 4K] ---/rwx SM=NUL Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8d3340fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8d853fe9 _pthread_cond_wait + 869 2 libHSrts_thr-ghc7.8.3.dylib 0x00000001152bde86 waitCondition + 6 3 libHSrts_thr-ghc7.8.3.dylib 0x0000000115297752 yieldCapability + 354 4 libHSrts_thr-ghc7.8.3.dylib 0x00000001152a7f26 schedule + 502 5 libHSrts_thr-ghc7.8.3.dylib 0x00000001152a7d17 scheduleWaitThread + 167 6 libHSrts_thr-ghc7.8.3.dylib 0x00000001152a3eea hs_main + 138 7 ghc 0x000000010e8c6d73 main + 115 8 ghc 0x000000010e7ddc34 start + 52 Thread 1 Crashed: 0 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x0000000115178811 __gmpn_addlsh2_n + 289 1 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x00000001151b87aa __gmpn_toom43_mul + 202 2 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x0000000115196c6b __gmpn_mul + 1835 3 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x000000011519d795 __gmpn_tdiv_qr + 3221 4 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x00000001151b4b88 __gmpz_tdiv_qr + 408 5 libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib 0x0000000115175b9f integer_cmm_quotRemIntegerzh + 207 6 libHSbase-4.7.0.1-ghc7.8.3.dylib 0x0000000114af08f0 c6Zm_info + 56 Thread 2: 0 libsystem_kernel.dylib 0x00007fff8d334f96 poll + 10 1 libHSbase-4.7.0.1-ghc7.8.3.dylib 0x0000000114be1444 cbep_info + 660 2 ??? 0x0000000115727e83 0 + 4654792323 Thread 3: 0 libsystem_kernel.dylib 0x00007fff8d334d16 kevent + 10 1 libHSbase-4.7.0.1-ghc7.8.3.dylib 0x0000000114ba3de5 cbpC_info + 173 2 libHSbase-4.7.0.1-ghc7.8.3.dylib 0x0000000114ba4908 cbuZ_info + 56 Thread 4: 0 libsystem_kernel.dylib 0x00007fff8d3340fa __psynch_cvwait + 10 1 libsystem_c.dylib 0x00007fff8d853fe9 _pthread_cond_wait + 869 2 libHSrts_thr-ghc7.8.3.dylib 0x00000001152bde86 waitCondition + 6 3 libHSrts_thr-ghc7.8.3.dylib 0x0000000115297752 yieldCapability + 354 4 libHSrts_thr-ghc7.8.3.dylib 0x00000001152a7f26 schedule + 502 5 libHSrts_thr-ghc7.8.3.dylib 0x00000001152a88bd scheduleWorker + 13 6 libsystem_c.dylib 0x00007fff8d84f7a2 _pthread_start + 327 7 libsystem_c.dylib 0x00007fff8d83c1e1 thread_start + 13 Thread 1 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x000000000000045b rcx: 0xfffffffffffffe84 rdx: 0x00000001154a0b68 rdi: 0x0000000115341bd0 rsi: 0x000000011549c5b8 rbp: 0x0000000115338f40 rsp: 0x0000000115338ec8 r8: 0x0000000000000001 r9: 0x0000000000000003 r10: 0x0000000000000003 r11: 0x0000000000000003 r12: 0xa37d223548939bc0 r13: 0x45cb5efb1fce45fd r14: 0x1ad82f94a68b146b r15: 0xaef755979088a4bb rip: 0x0000000115178811 rfl: 0x0000000000010286 cr2: 0x0000000115341000 Logical CPU: 2 Binary Images: 0x10e7dc000 - 0x10e8cafff +ghc (???) <515FEFFC-8563-3E63-A019-2D36A4E5B376> /usr/local/lib/ghc-7.8.3/bin/ghc 0x10e98f000 - 0x10ea80ff7 +libHShaskeline-0.7.1.2-ghc7.8.3.dylib (0) <77838A66-EC3D-3443-AA05-484564631E96> /usr/local/lib/ghc-7.8.3/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.3.dylib 0x10eb8e000 - 0x10eba8fff +libHSterminfo-0.4.0.0-ghc7.8.3.dylib (0) /usr/local/lib/ghc-7.8.3/terminfo-0.4.0.0/libHSterminfo-0.4.0.0-ghc7.8.3.dylib 0x10ebd8000 - 0x111533ff7 +libHSghc-7.8.3-ghc7.8.3.dylib (0) <7496A043-6E06-3D38-9E0C-86B2F1443163> /usr/local/lib/ghc-7.8.3/ghc-7.8.3/libHSghc-7.8.3-ghc7.8.3.dylib 0x112fe9000 - 0x113037ffe +libHStransformers-0.3.0.0-ghc7.8.3.dylib (0) <760D119E-6E9D-3958-8EBD- 5FD0AE08F661> /usr/local/lib/ghc-7.8.3/transformers-0.3.0.0/libHStransformers-0.3.0.0-ghc7.8.3.dylib 0x1130d0000 - 0x113217ffb +libHStemplate- haskell-2.9.0.0-ghc7.8.3.dylib (0) <07A381B5-881A-34E7-A336-ED1E94B69C3D> /usr/local/lib/ghc-7.8.3/template-haskell-2.9.0.0/libHStemplate- haskell-2.9.0.0-ghc7.8.3.dylib 0x1133a2000 - 0x1133b9ff8 +libHShpc-0.6.0.1-ghc7.8.3.dylib (0) <90B745B0-63A3-3339-8D3C-1D0864FFB3ED> /usr/local/lib/ghc-7.8.3/hpc-0.6.0.1/libHShpc-0.6.0.1-ghc7.8.3.dylib 0x1133e0000 - 0x113427fff +libHShoopl-3.10.0.1-ghc7.8.3.dylib (0) <40C41B4C-9A7B-3179-876C- 648C08E50D0C> /usr/local/lib/ghc-7.8.3/hoopl-3.10.0.1/libHShoopl-3.10.0.1-ghc7.8.3.dylib 0x11349a000 - 0x1134abffe +libHSbin-package- db-0.0.0.0-ghc7.8.3.dylib (0) <3C63EAE8-C8F7-3E49-845E-51BB912CAD10> /usr/local/lib/ghc-7.8.3/bin-package-db-0.0.0.0/libHSbin-package- db-0.0.0.0-ghc7.8.3.dylib 0x1134be000 - 0x113510ff9 +libHSbinary-0.7.1.0-ghc7.8.3.dylib (0) <19FB0D1E-CADF-369D-AB5F- EFE63DB78B47> /usr/local/lib/ghc-7.8.3/binary-0.7.1.0/libHSbinary-0.7.1.0-ghc7.8.3.dylib 0x11355d000 - 0x113b35ffe +libHSCabal-1.18.1.3-ghc7.8.3.dylib (0) <6E368272-1A7F- 3C57-AAB0-4EBFC9AB09B2> /usr/local/lib/ghc-7.8.3/Cabal-1.18.1.3/libHSCabal-1.18.1.3-ghc7.8.3.dylib 0x114104000 - 0x114113fff +libHSprocess-1.2.0.0-ghc7.8.3.dylib (0) /usr/local/lib/ghc-7.8.3/process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.3.dylib 0x11412a000 - 0x11413affe +libHSpretty-1.1.1.1-ghc7.8.3.dylib (0) <2CC28F0F-6F2F-3CEC-8A6F- DB9633147377> /usr/local/lib/ghc-7.8.3/pretty-1.1.1.1/libHSpretty-1.1.1.1-ghc7.8.3.dylib 0x114151000 - 0x1142bcffe +libHScontainers-0.5.5.1-ghc7.8.3.dylib (0) <511470B1-0294-3F78-8BB7-CDC53E592EE1> /usr/local/lib/ghc-7.8.3/containers-0.5.5.1/libHScontainers-0.5.5.1-ghc7.8.3.dylib 0x1143b1000 - 0x1143bffff +libHSdirectory-1.2.1.0-ghc7.8.3.dylib (0) /usr/local/lib/ghc-7.8.3/directory-1.2.1.0/libHSdirectory-1.2.1.0-ghc7.8.3.dylib 0x1143d7000 - 0x114431ff7 +libHSunix-2.7.0.1-ghc7.8.3.dylib (0) <82865E9A-9BBF-32B9-8A8A-31C61A1A87D7> /usr/local/lib/ghc-7.8.3/unix-2.7.0.1/libHSunix-2.7.0.1-ghc7.8.3.dylib 0x1144c3000 - 0x11454cfff +libHStime-1.4.2-ghc7.8.3.dylib (0) <9F64C699-AEC9-372D-A926-A3D9114E5A40> /usr/local/lib/ghc-7.8.3/time-1.4.2/libHStime-1.4.2-ghc7.8.3.dylib 0x1145fb000 - 0x114601ffb +libHSold- locale-1.0.0.6-ghc7.8.3.dylib (0) <1D324A30-3A30-3C2B-855B-BBE85CD3E46E> /usr/local/lib/ghc-7.8.3/old-locale-1.0.0.6/libHSold- locale-1.0.0.6-ghc7.8.3.dylib 0x114611000 - 0x114621ffd +libHSfilepath-1.3.0.2-ghc7.8.3.dylib (0) <6A655401-5A48-3311-9F47-4913B98A1835> /usr/local/lib/ghc-7.8.3/filepath-1.3.0.2/libHSfilepath-1.3.0.2-ghc7.8.3.dylib 0x11463e000 - 0x1146c9fff +libHSbytestring-0.10.4.0-ghc7.8.3.dylib (0) <37CA9ED5-C80A-3AEB- AE07-563EA9F8E0BC> /usr/local/lib/ghc-7.8.3/bytestring-0.10.4.0/libHSbytestring-0.10.4.0-ghc7.8.3.dylib 0x11475a000 - 0x11475cff8 +libHSdeepseq-1.3.0.2-ghc7.8.3.dylib (0) /usr/local/lib/ghc-7.8.3/deepseq-1.3.0.2/libHSdeepseq-1.3.0.2-ghc7.8.3.dylib 0x114769000 - 0x1147d4ff9 +libHSarray-0.5.0.0-ghc7.8.3.dylib (0) <40F4C2AD-861A-3048-AE8D-970E3D6915D3> /usr/local/lib/ghc-7.8.3/array-0.5.0.0/libHSarray-0.5.0.0-ghc7.8.3.dylib 0x11483f000 - 0x114c17ff7 +libHSbase-4.7.0.1-ghc7.8.3.dylib (0) <363FAE50-2090-3B3F-B9CC-BAF20493C5A9> /usr/local/lib/ghc-7.8.3/base-4.7.0.1/libHSbase-4.7.0.1-ghc7.8.3.dylib 0x115167000 - 0x1151d8fc7 +libHSinteger- gmp-0.5.1.0-ghc7.8.3.dylib (0) <1904D998-1201-3691-BFA6-0B7E8C73D9E2> /usr/local/lib/ghc-7.8.3/integer-gmp-0.5.1.0/libHSinteger- gmp-0.5.1.0-ghc7.8.3.dylib 0x1151f7000 - 0x115240ff7 +libHSghc- prim-0.3.1.0-ghc7.8.3.dylib (0) <7A005B4C-2B84-3FC4-8A8E-F4384C458F17> /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib 0x115295000 - 0x1152e5fff +libHSrts_thr-ghc7.8.3.dylib (0) /usr/local/lib/ghc-7.8.3/rts-1.0 /libHSrts_thr-ghc7.8.3.dylib 0x11530d000 - 0x115310fff +libffi.dylib (7) /usr/local/lib/ghc-7.8.3/rts-1.0/libffi.dylib 0x7fff6e3dc000 - 0x7fff6e41093f dyld (210.2.3) /usr/lib/dyld 0x7fff83549000 - 0x7fff8354cff7 libdyld.dylib (210.2.3) /usr/lib/system/libdyld.dylib 0x7fff839a7000 - 0x7fff839afff7 libsystem_dnssd.dylib (379.38.1) /usr/lib/system/libsystem_dnssd.dylib 0x7fff83e54000 - 0x7fff83ea0ff7 libauto.dylib (185.4) /usr/lib/libauto.dylib 0x7fff848cc000 - 0x7fff848d1fff libcache.dylib (57) <65187C6E- 3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib 0x7fff8519c000 - 0x7fff851a7fff libsystem_notify.dylib (98.5) /usr/lib/system/libsystem_notify.dylib 0x7fff8750c000 - 0x7fff8750dfff libsystem_blocks.dylib (59) /usr/lib/system/libsystem_blocks.dylib 0x7fff8787a000 - 0x7fff87888fff libcommonCrypto.dylib (60027) /usr/lib/system/libcommonCrypto.dylib 0x7fff8793e000 - 0x7fff8793fff7 libremovefile.dylib (23.2) <6763BC8E-18B8-3AD9-8FFA-B43713A7264F> /usr/lib/system/libremovefile.dylib 0x7fff8798b000 - 0x7fff8798cff7 libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib 0x7fff87bd0000 - 0x7fff87bd2ff7 libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib 0x7fff88180000 - 0x7fff8818eff7 libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib 0x7fff8822b000 - 0x7fff88233fff liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib 0x7fff88395000 - 0x7fff8848afff libiconv.2.dylib (34) /usr/lib/libiconv.2.dylib 0x7fff889a9000 - 0x7fff88ac192f libobjc.A.dylib (532.2) <90D31928 -F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib 0x7fff89440000 - 0x7fff89442fff libquarantine.dylib (52.1) <143B726E-DF47-37A8-90AA-F059CFD1A2E4> /usr/lib/system/libquarantine.dylib 0x7fff89696000 - 0x7fff896c4ff7 libsystem_m.dylib (3022.6) /usr/lib/system/libsystem_m.dylib 0x7fff896c5000 - 0x7fff896e7ff7 libxpc.dylib (140.43) <70BC645B-6952-3264-930C-C835010CCEF9> /usr/lib/system/libxpc.dylib 0x7fff8ac55000 - 0x7fff8ac5afff libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib 0x7fff8bb78000 - 0x7fff8bb8dff7 libdispatch.dylib (228.23) /usr/lib/system/libdispatch.dylib 0x7fff8d2d2000 - 0x7fff8d321ff7 libcorecrypto.dylib (106.2) /usr/lib/system/libcorecrypto.dylib 0x7fff8d322000 - 0x7fff8d33dff7 libsystem_kernel.dylib (2050.24.15) /usr/lib/system/libsystem_kernel.dylib 0x7fff8d83b000 - 0x7fff8d907ff7 libsystem_c.dylib (825.26) <4C9EB006-FE1F-3F8F-8074-DFD94CF2CE7B> /usr/lib/system/libsystem_c.dylib 0x7fff8d9d9000 - 0x7fff8d9d9fff libkeymgr.dylib (25) /usr/lib/system/libkeymgr.dylib 0x7fff8dce2000 - 0x7fff8dce3fff libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8dd40000 - 0x7fff8dd41ff7 libsystem_sandbox.dylib (220.3) /usr/lib/system/libsystem_sandbox.dylib 0x7fff8eb49000 - 0x7fff8eb4aff7 libdnsinfo.dylib (453.19) <14202FFB-C3CA-3FCC-94B0-14611BF8692D> /usr/lib/system/libdnsinfo.dylib 0x7fff8eb4b000 - 0x7fff8eb70ff7 libc++abi.dylib (26) /usr/lib/libc++abi.dylib 0x7fff8ebc5000 - 0x7fff8ec2dff7 libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib 0x7fff8f14c000 - 0x7fff8f152fff libmacho.dylib (829) /usr/lib/system/libmacho.dylib 0x7fff8f26d000 - 0x7fff8f2a5fff libncurses.5.4.dylib (37.3) <68D5B5F5-8252-3F1E-AFF1-C6AFE145DBC1> /usr/lib/libncurses.5.4.dylib 0x7fff8f4ef000 - 0x7fff8f4f6fff libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib 0x7fff8f746000 - 0x7fff8f77cfff libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib 0x7fff8f77d000 - 0x7fff8f783ff7 libunwind.dylib (35.1) <21703D36 -2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 11291 thread_create: 1 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=159.5M resident=138.3M(87%) swapped_out_or_unallocated=21.2M(13%) Writable regions: Total=52.5M written=21.6M(41%) resident=23.9M(46%) swapped_out=0K(0%) unallocated=28.6M(54%) REGION TYPE VIRTUAL =========== ======= MALLOC 18.2M MALLOC guard page 16K STACK GUARD 56.0M Stack 10.0M VM_ALLOCATE 19.0M __DATA 5892K __LINKEDIT 93.8M __TEXT 65.7M shared memory 12K =========== ======= TOTAL 268.5M }}} $ ghc --info {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/local/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/lib/ghc-7.8.3/package.conf.d") ] }}} $ gcc --version {{{ gcc (GCC) 4.9.0 20140302 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} Please let me know if there's more I can do to help. I'd be willing to try and track down the issue myself, but I'm afraid I know next to nothing about ghc and it would probably take a lot more work helping me than it would to fix the issue otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 27 21:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jul 2014 21:36:22 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.6b46f5af8841589173c9b4fa98ed03b7@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Iavor S. Diatchki ): In [changeset:"97f499b56c5888740ddb147fb198c28a3c06bac7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="97f499b56c5888740ddb147fb198c28a3c06bac7" Implement OVERLAPPING and OVERLAPPABLE pragmas (see #9242) This also removes the short-lived NO_OVERLAP pragama, and renames OVERLAP to OVERLAPS. An instance may be annotated with one of 4 pragams, to control its interaction with other overlapping instances: * OVERLAPPABLE: this instance is ignored if a more specific candidate exists * OVERLAPPING: this instance is preferred over more general candidates * OVERLAPS: both OVERLAPPING and OVERLAPPABLE (i.e., the previous GHC behavior). When compiling with -XOverlappingInstances, all instance are OVERLAPS. * INCOHERENT: same as before (see manual for details). When compiling with -XIncoherentInstances, all instances are INCOHERENT. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 00:13:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 00:13:54 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.014cfe4632d3026cb4d143b639e0d2cd@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by rwbarton): Thanks, that was helpful. GMP does large temporary allocations in, for example, `mpn_mul`. Somehow, we are configuring GMP to use `alloca` for temporary allocations. In the most recent report, we happened to `alloca` past the stack guard page and a malloc guard page, and then we crashed when we wrote into the "allocated" memory that was actually the malloc guard page. (Note that the "Stack" VM region is not actually the stack, it's a stack guard page.) In the original report, it's hard to tell what's going on with no symbols (due to the old ghci linker) but it looks like we may have `alloca`ed directly into the stack guard page. I imagine that we only saw this in ghci because non-threaded programs have larger stack areas (and maybe no guard pages). GMP's temporary allocation method is controlled by the CPP symbols `WANT_TMP_ALLOCA`, `WANT_TMP_REENTRANT` etc. I don't understand how it is happening that we build with `WANT_TMP_ALLOCA` when (per `configure.in`) the default setting for `--enable-alloca` is `reentrant`. But I was able to confirm from examining `libHSinteger-gmp-0.5.1.0-ghc7.8.3.dylib` that it is using `alloca`, and mzero also provided the [http://lpaste.net/108250 config.h] file from his build of GHC which includes `#define WANT_TMP_ALLOCA 1`. `WANT_TMP_REENTRANT` is the default, and what Debian's build of libgmp uses, so we should just use that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 00:20:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 00:20:07 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.0973102e251f94acc3bfed37aeebf98b@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- My intuition follows dfeuer's in this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 01:33:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 01:33:14 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.02b64536649958975cf5cab4dde8760a@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by rwbarton): Actually a few things were not quite right in that. `--enable- alloca=reentrant` is not the same as `WANT_TMP_REENTRANT`! It means "use `WANT_TMP_ALLOCA` if you have `alloca`, otherwise use `WANT_TMP_REENTRANT`". So that explains how `WANT_TMP_ALLOCA` is getting set. Also, my examination of the Debian `libgmp.so.10` was overly hasty. It is actually built with `WANT_TMP_ALLOCA`. There are several allocation paths in `mpn_mul`, and some call `malloc` when the amount to be allocated exceeds a certain threshold, while others unconditionally allocate on the stack. Not sure what the best thing to do here is aside from resorting to `WANT_TMP_REENTRANT`, which I fear may carry a noticeable performance penalty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 01:54:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 01:54:08 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.0f32fefe1f473fb3d14160bf1cbe01e5@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by rwbarton): So GMP 6 has (as I mentioned above) a macro to allocate small blocks with `alloca` and large blocks with `malloc`. The current release does not correctly use this macro in the code in question, but [https://gmplib.org/repo/gmp-6.0/rev/84965a50fd92 this backported patch] fixes this. So if we wait for GMP 6.0.1 and then update the in-tree tarball, this should get fixed automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 02:05:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 02:05:30 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.0c5dc8aefb6cfd6b741ef17f5a00b283@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Response from Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 02:07:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 02:07:21 -0000 Subject: [GHC] #9371: Overlapping type families, segafult Message-ID: <044.67d504251b4c6afbb591b885728a5986@haskell.org> #9371: Overlapping type families, segafult ----------------------------------+---------------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- Not entirely sure what's going on here. I don't think this should type check; it appears to segfault whilst calling show on the wrong type. This is probably not the absolute minimum required to reproduce. I have reproduced on 7.8.3 and 7.9.20140727. {{{#!haskell {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} import Data.Monoid class C x where data D x :: * makeD :: D x instance Monoid x => C x where data D x = D1 (Either x ()) makeD = D1 (Left mempty) instance (Monoid x, Monoid y) => C (x, y) where data D (x,y) = D2 (x,y) makeD = D2 (mempty, mempty) instance Show x => Show (D x) where show (D1 x) = show x main = print (makeD :: D (String, String)) }}} This does not segfault if you add: {{{#!haskell instance (Show x, Show y) => Show (D (x,y)) where show (D2 x) = show x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 02:23:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 02:23:56 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.dca3b3921b7aad337621ef02d6cd3e89@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by goldfire): If we make the associated data instance an associated ''type'' instance, the module fails to compile. Perhaps it should fail too for data families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 02:25:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 02:25:15 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.36ba213b2812a22024550714c24b3f57@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): It should suffice to do a second build of gmp with `--enable-shared=yes`, right? I see there is the beginnings of some code in `gmp/ghc.mk` to do this already, but it's very old, not sure what the story is there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 02:58:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 02:58:06 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.f2f2032d2d09812b959c47424b11b92e@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by carter): {{{ main = print (makeD :: D (String, String)) }}} this seems to be ambiguous wrt which D constructor is chosen, right? (at least wrt the instance of class C and thence makeD right?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 03:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 03:08:59 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.162fcccb1a862c9c0dde75245633b022@haskell.org> #7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This issue affects both Win32 consoles (e.g., cmd.exe) and mintty consoles (e.g., Cygwin and MSYS), but in different ways. In mintty consoles, the issue is easily fixed by setting the encoding of the file handle to {{{utf8}}}: {{{ > putStrLn "?" *** Exception: : hPutChar: invalid argument (invalid character) > import System.IO > hSetEncoding stdout utf8 > putStrLn "?" ? > getChar >>= putChar ? ?> getChar >>= putChar ?> getChar >>= putChar ?> getChar >>= putChar > hSetEncoding stdin utf8 > getChar >>= putChar ? ?> }}} Fixing the issue on Win32 consoles is not as easy. One approach is to use the FFI to call the native API calls for Unicode output ([http://msdn.microsoft.com/en- us/library/windows/desktop/ms687401%28v=vs.85%29.aspx WriteConsoleW]) and input ([http://msdn.microsoft.com/en- us/library/windows/desktop/ms684961%28v=vs.85%29.aspx ReadConsoleInputW]). This is the approach that [https://github.com/judah/haskeline/blob/0f4ba2c51691f2031371c0bfadcd652abf57ad27/System/Console/Haskeline/Backend/Win32.hsc haskeline] takes, and it seems to work well: {{{ > import System.Console.Haskeline > import Data.Maybe > runInputT defaultSettings (getInputChar "") >>= runInputT defaultSettings . outputStrLn . (:[]) . fromJust ? ? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 03:33:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 03:33:02 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux Message-ID: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------+---------------------------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- Trying to compile GHC 7.8.3 for ubuntu/arm. Was in Stage 1 for 8 hours before exiting with following message: dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 05:00:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 05:00:04 -0000 Subject: [GHC] #9373: typeable instances incompatible between 7.8 and 7.9 Message-ID: <045.7c6fd875d64070d2851c30b5f2b85c67@haskell.org> #9373: typeable instances incompatible between 7.8 and 7.9 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- not sure if this is deliberate or by design, but to get some typeable instances happy for some DataKind heavy code, if i wish it to build in both 7.8 and 7.9, i need to write it in the following form {{{#!hs {-# LANGUAGE DataKinds, GADTs, TypeFamilies, TypeOperators, ConstraintKinds, ScopedTypeVariables, RankNTypes #-} data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ >= 707) && ( __GLASGOW_HASKELL__ < 709) deriving instance Typeable 'Z deriving instance Typeable 'S #endif }}} if i omit the latter typeables in 7.8, i can't get typeable instances for Nat indexed data types, but i get a GHC error if i include them in 7.9 {{{ Duplicate instance declarations: instance Typeable 'S -- Defined at src/Numerical/Nat.hs:24:28 instance Typeable 'S -- Defined at src/Numerical/Nat.hs:28:1 src/Numerical/Nat.hs:24:28: Duplicate instance declarations: instance Typeable 'Z -- Defined at src/Numerical/Nat.hs:24:28 instance Typeable 'Z -- Defined at src/Numerical/Nat.hs:27:1 }}} https://travis-ci.org/wellposed/numerical/jobs/31011288#L525 for context I can work around it with CPP, but is this a deliberate change or accidental? (i'm ok with that CPP being there, but would like some confirmation this is a deliberate change) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 05:55:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 05:55:37 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.91eb042357c7ef62ef28ec5d78b07a96@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by jstolarek): I admit I am not certain if I can reliably produce such a specification. But I will be thinking about it. Regarding first bullet: my plan was to change the representation of arrow notation in HsSyn. Would you like the specification to contain current representation or the planned new one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 06:16:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 06:16:11 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.2d06e6e35bfa75b1b638900345ba4f4d@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): I think this should also be mentioned in the release notes for 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 06:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 06:46:08 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.425fbad29a1e47a24856121d7752ce22@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by hvr): Replying to [comment:33 rwbarton]: > So if we wait for GMP 6.0.1 and then update the in-tree tarball, this should get fixed automatically. I'd rather get rid of the in-tree GMP tarball altogether than updating it, as it will increase the ghc.git history by a 2MiB blob everyone will have to download each time `ghc.git` gets cloned. Morever, the work I'm doing in #9281 is also somewhat motivated by finally getting rid of the in-tree GMP tarball for good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:04:35 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.4b030cee28a532531040e720b37ed7f2@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Adding `-dshow-passes` will show you the size of the intermediates of each pass. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:21:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:21:51 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation Message-ID: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. The comment in DynFlags says: {{{ Max writes: I think it's probably best not to enable SAT with -O2 for the 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate several improvements to the heuristics, and I'm concerned that without those changes SAT will interfere with some attempts to write "high performance Haskell", as we saw in some posts on Haskell-Cafe earlier this year. In particular, the version in HEAD lacks the tail call criterion, so many things that look like reasonable loops will be turned into functions with extra (unneccesary) thunk creation. }}} 6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:24:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:24:22 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.7ff22108e1d89599a849676e4e6efaa2@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * priority: low => normal Comment: `-fstatic-argument-transformation` description in 4.20.15 says it is implied by `-O2` but that is not the case. It looks like these two sections of the user guide really need updating - bumping priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:50:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:50:50 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.a5cfeb459a6474089169609b66748428@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): The new one. After all, the new one is what you propose! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:52:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:52:22 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.5d5c7bf6c35fe6cf9a69221968306dd4@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Excellent -- would you feel able to submit a patch? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 07:59:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 07:59:02 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.0b2a5f69d31489b8cde55dd1e1bdf09d@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: nicolas.frisby@? (added) Comment: That would be great. Quick thoughts * As I recall, in [http://research.microsoft.com/en- us/um/people/simonpj/papers/santos-thesis.ps.gz Andre Santos's thesis] he got ambiguous results from SAT: some programs improved, some got worse. * Also worth reading: Danvy et al's paper about "lambda-dropping" * The places it got worse might well be fixed by Nick Frisby's work on "late lambda lifting". Sadly, this has stalled a bit because Nick has got interested in other things. I'm copying him in the hope of an update. It would be great to re-instate SAT. But it would need someone to do some careful benchmarking to make sure that it yielded a net benefit. What usually happens is that you find a couple of cases where it makes things worse, investigate, find why, and modify the transformation to avoid them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 08:00:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 08:00:19 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.c66a79a5dbac262669e9c4d934113b81@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): If no one steps up then I'll probably do it before 7.10 gets released. This is a simple thing to fix but I estimate that checking all the flags and fixing their descriptions is about 4 hours of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 08:03:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 08:03:11 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.50d3c4232c7fcc855d8e3120d8b7b302@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I found an email summarising a conversation Max and I had about SAT, back in 2009. Here it is verbatim, FWIW: SAT can lose; eg * few static args (can spot) * few loop iterations (hard to spot) * SAT changes SpecConstr opportunity into CaseLib opportunity; and the latter is not good at the moment * SATing exposes new loop-invariant sub-expressions e.g. {{{ f x y = if y==0 then 0 else g x + f x (y-1) }}} That is potentially good. But float-out can be bad for cold branches, and this can be bad. Hence want to focus on SAT in situations where it?s most likely to benefit. SAT has benefits of two kinds: 1. More efficient loops, when there are a lot of static args. This is a pretty small effect. 2. Specialisation from (a) SAT makes recursive function non-rec; (b) then inlining can happen. This is the big gain. Evidence for (2): most benefits happen even if you SAT *only* if at least one SAT-d argument has function type. Four exceptions, where SATing non-function-typed args was worthwhile: * Atom. f x y = (x,y) : f x y. Satting this makes an loopy list; result 97% reduction in runtime. * SAT may make a function small enough to fit inside inlining threshold. * Puzzle. Recursive SAT-able function called just once outside. After SAT, it can be inlined, and hence specialised for the (single) call site. One program got worse when SATing non-function-typed args * Listcompr. The cold-branch problem happens. Thoughts: * No point in SAT if function is big. Maybe SAT only if EITHER small OR single call site outside. * Max?s idea: * Lambda lift everything * !SpecConstr * Lambda-drop * Export unfoldings * Selectively lambda-lift (lambda-lift functions of only one argument) [SLPJ: this is Nick Frisby's work] * Codegen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 08:06:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 08:06:33 -0000 Subject: [GHC] #9373: typeable instances incompatible between 7.8 and 7.9 In-Reply-To: <045.7c6fd875d64070d2851c30b5f2b85c67@haskell.org> References: <045.7c6fd875d64070d2851c30b5f2b85c67@haskell.org> Message-ID: <060.f82615d1c530e138fd1ba9bacd33e259@haskell.org> #9373: typeable instances incompatible between 7.8 and 7.9 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I'm afraid it's deliberate: #8950. Unless you want to argue to reverse the design decision taken there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 08:22:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 08:22:26 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.136b0b5036818215bb9f991b9b8aed48@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-frule-check` flag is not described at all. Here's an excerpt from `Rules.lhs`: {{{ We want to know what sites have rules that could have fired but didn't. This pass runs over the tree (without changing it) and reports such. \begin{code} -- | Report partial matches for rules beginning with the specified -- string for the purposes of error reporting }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 09:13:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 09:13:23 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.cf8c43a6021174207859d5a1494f792f@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-flate-dmd-anal` description in 4.10.2 has incorrect link to the Trac wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 09:32:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 09:32:09 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.44ec445ec331bbfc38e4e3a22b9842b5@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by simonpj): * cc: goldfire, dimitris@?, sweirich@?, nomeata, Conor.McBride@? (added) Comment: Great bug! I know exactly what is going on. There is a long-standing awkwardness in GHC?s implementation of newtype, described in `Note [Newtype eta]` in `TyCon`, which I reproduce below. The core of it comes down to this. Consider {{{ newtype Parser a = MkParser (IO a) derriving( Monad ) }}} Do we have `(Monad Parser ~R Monad IO)`? These are the types of the Monad dictionaries for Parser and IO resp. In the olden days to implement Generalised Newtype Deriving (GND) we coerced directly between these dictionary types, so we really needed them to be ~R. As a result, the axiom induced by the above newtype had to be {{{ ax :: Parser ~R IO }}} and not {{{ ax a :: Parser a ~R IO a }}} So we had to eta-reduce axioms. This is a royal pain. And we have to do it for newtype instances too. See `Note [Eta reduction for data family axioms]` in `TcInstDcls`. And it turns out that the new, serious bug #9371 is directly attributable to this royal pain. Side note: our [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ Safe coercions? paper] does not say in Section 2 how to deal with data/newtype instances. NOW, in our new story for GND, we never coerce between `Monad Parser` and `Monad IO`. Instead we coerce the individual methods (Section 7 of the paper). Why? I think it?s because our roles are not higher-kinded, but we didn?t document the change. Does anyone else remember? I think there were actually multiple reasons. However this change means that we DON?T need `(IO ~R Parser)` any more! Only `(IO ty ~R Parser ty)`. So the reason for the eta reduction seems to have gone away. Do you agree? If so I could simplify GHC by removing the complicated eta stuff. I would rather do that than fix #9371 by adding more complexity I see that this was actually proposed in #8503, but the thread diverged onto other matters. Richard?s last comment:7 said ?So we don't need eta- reduction as much as maybe we once did, but it's still useful.? but provided no evidence in support of this claim. I somehow think this is connected to #9123 but I can?t put my finger on why. Simon {{{ Note [Newtype eta] ~~~~~~~~~~~~~~~~~~ Consider newtype Parser a = MkParser (IO a) derriving( Monad ) Are these two types equal (to Core)? Monad Parser Monad IO which we need to make the derived instance for Monad Parser. Well, yes. But to see that easily we eta-reduce the RHS type of Parser, in this case to ([], Froogle), so that even unsaturated applications of Parser will work right. This eta reduction is done when the type constructor is built, and cached in NewTyCon. The cached field is only used in coreExpandTyCon_maybe. Here's an example that I think showed up in practice Source code: newtype T a = MkT [a] newtype Foo m = MkFoo (forall a. m a -> Int) w1 :: Foo [] w1 = ... w2 :: Foo T w2 = MkFoo (\(MkT x) -> case w1 of MkFoo f -> f x) After desugaring, and discarding the data constructors for the newtypes, we get: w2 :: Foo T w2 = w1 And now Lint complains unless Foo T == Foo [], and that requires T==[] This point carries over to the newtype coercion, because we need to say w2 = w1 `cast` Foo CoT so the coercion tycon CoT must have kind: T ~ [] and arity: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 09:44:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 09:44:26 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.5ebfe50eb77d3c45624b2974aa117d46@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-fdo-lambda-eta-expansion` description in 4.20.15 says: "Enable lambda eta-reduction". Obviously, it does the opposite. Ugh... what a mess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 10:07:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 10:07:06 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.b0e79e9bba1a9c79f1d22583f116805d@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-Odph` is not listed in the flag reference section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 11:48:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 11:48:39 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.6de4ccaaece8e5974482d25b4129873d@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I've added a reply, as below. Is it ok to remove the para about "non- parametric" equations? '''Simon:''' I agree that, since type syononyms can't be recursive except via a data type, if you use "A possible variation" below, then you can get away with saying that type synonyms cannot have CUSKs. It seems a bit non-orthogonal; and could occasionally be tiresome. Imagine {{{ data T1 a b c = ...S... data T2 p q r = ...S... data T3 x y q = ...S... type S f g h = ...T1...T2...T3... }}} Then, since you can't decorate S with a CUSK, you might need to annotate all of T1, T2 and T3 with CUSKs. It would not be hard to say what a CUSK for a type synonym was: just wrap the whole RHS in a kind signature: {{{ type T (a::k1) (b::k1->k2) = b a :: k2 }}} I think I'd argue mildy for that, just to make the design orthogonal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 11:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 11:59:24 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.ed44ff529a339d55343f2e933dd9ea53@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by goldfire): At first reading, it seemed that comment:3 did not relate to this ticket. But, looking closer, I see how. I'll explain for others' benefit: The line `data D x = D1 (Either x ())` becomes somewhat like the two declarations {{{ data DFInst1 x = D1 (Either x ()) type D x = DFInst1 x }}} We create a proper datatype `DFInst1` that has no eta-reduction or anything strange, really, other than the fact that the user can't ever write its name. Data families are internally interpreted somewhat like type families, and thus we create the connection between `D` and `DFInst1`. However, as Simon explains, the ''second'' of my definitions above is eta-reduced. When processing `data D (x, y) = D2 (x, y)`, the relevant type-ish instance is `D (x, y) = DFInst2 x y`, which can''not'' be eta-reduced. Then, when comparing the instances `D = DFInst1` and `D (x, y) = DFInst2 x y`, the conflict-checker says that the left-hand sides (`` and `(x,y)`, respectively) are quite surely apart, because they are of different lengths! There is a fix here that involves much less theory than Simon's approach: fix the conflict checker to take this into account. There should ''never'' be different lengths involved here (absent the eta-reduction), so when there are, we could just note a conflict. Even simpler, we could notice somehow that a data family is involved and spit out a conflict right away, as two data family instances are ''never'' compatible. That said, Simon asks a worthwhile question: do we need eta-reduction given the new implementation of GND? I think "yes": {{{ import Control.Monad.Trans.Identity newtype MyList a = MkList [a] class C m where x :: IdentityT m Int instance C [] where x = IdentityT [1,2,3] deriving instance C MyList }}} This (silly) example requires the eta-reduction to work, and I don't see a compelling reason to reduce expressivity here. Yes, it would simplify the code somewhat, but I still don't think it's worth it. In answer to Simon's "why not cast `Monad Parser` to `Monad IO`": a lack of higher-kinded roles was a big part of the discussion, but there was another: superclasses. It's possible that the GND'd class has superclasses and that the superclass instances for the original type and the newtype are different. If we casted the whole instance, we would get the superclass instances from the original type, which would be quite strange. Indeed, before making any change related to roles, the old GND code also did not cast instances, because of this superclass issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 12:44:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 12:44:16 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.2427447962ca2d43be9a8b71415d3180@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonpj): "Fix the conflict checker" is clearly an option. It's what I described as "adding more complexity". Moreover, let us note that GHC's current behaviour is not documented in the user manual or in any paper. If you are arguing to stick with it, we should at least write it up! Any volunteers? Moreover, doesn't your example work perfectly well without eta reduction? To typecheck the `deriving instance` we need {{{ IdentityT [] Int ~R IdentityT MyList Int }}} Now, using the `Coercible` instances in Fig 2 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf the paper], we can reduce that to {{{ [Int] ~R MyList Int }}} and that is true with the non-eta-reduced axiom. If `IdentityT`'s data constructor was not in scope, then indeed the program will still typecheck -- but arguably doing so exposes something about the representation of the newtype, harming abstraction. You certainly couldn't have written it be hand. It all seems quite debatable to me. Do we really want a significant cluster of complexity in the implementation, to implement an un-documented feature, which no one is asking for, and whose very existence is debatable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 12:55:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 12:55:49 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module In-Reply-To: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> References: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> Message-ID: <064.7031416534d8b3bac2123319ecf5689a@haskell.org> #9294: More exports and documentation for GHC API Parser Module -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: GHC API | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D71 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: This was merged - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 12:55:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 12:55:54 -0000 Subject: [GHC] #9294: More exports and documentation for GHC API Parser Module In-Reply-To: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> References: <049.dab519b9942af0b5bcc58ee162b1432d@haskell.org> Message-ID: <064.bb82dae0e1b470416fb8f9cbdc11506b@haskell.org> #9294: More exports and documentation for GHC API Parser Module -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: GHC API | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D71 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 13:45:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 13:45:03 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.2a402e73ec95245301a5e67b5053086a@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Great stuff, thank you. I'll now deprecate `-XOverlappingInstances`. To finish this off I'd love someone to make INOCOHERET per-instance too! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 13:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 13:46:58 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.ccc5285d558e63dff793254bfc3e44c5@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Since TH syntax can't represent the declaration it's bizarre that it's accepted. But it wouldn't be hard to implement. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 13:48:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 13:48:18 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.c13e983712338525a6f57f65d8112999@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by goldfire): Replying to [comment:5 simonpj]: > > Moreover, doesn't your example work perfectly well without eta reduction? To typecheck the `deriving instance` we need > {{{ > IdentityT [] Int ~R IdentityT MyList Int > }}} > Now, using the `Coercible` instances in Fig 2 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf the paper], we can reduce that to > {{{ > [Int] ~R MyList Int > }}} > and that is true with the non-eta-reduced axiom. > > If `IdentityT`'s data constructor was not in scope, then indeed the program will still typecheck -- but arguably doing so exposes something about the representation of the newtype, harming abstraction. You certainly couldn't have written it be hand. I hadn't considered the newtype-unwrapping axiom when writing the example. You're right -- we don't need eta reduction. But, if `IdentityT` were a ''data''type instead of a newtype, we would, without further changes to the example. The "harming abstraction" note is exactly the debate about whether or not we should be able to coerce `Map String Int` to `Map String Age` without `Map`'s constructor being in scope. > > It all seems quite debatable to me. Do we really want a significant cluster of complexity in the implementation, to implement an un-documented feature, which no one is asking for, and whose very existence is debatable? It still makes me nervous to reduce expressiveness -- I just don't want users of 7.10 to suddenly lose something, post here that they need it back, and then have it restored for 7.12, leaving a lot of CPP in their code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 13:51:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 13:51:28 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.4b9e339e9c16238b164a0621379859f5@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I'll move this from my local, unpublicized, unofficial set of tickets I plan to address to my official set of tickets I plan to address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:02:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:02:19 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.6f099bf08e54b6600a6e58a31f533629@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): What about {{{ type S (a :: k) = Proxy (T (Just a)) data T a = MkT (S a) }}} Does that `S` have a CUSK? If it does, the code should be accepted, I think. Or, would a user have to put in a totally-superfluous ` :: *` at the end of `S`'s RHS? Regardless of the kind of `T`, a proxy is always in kind `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:34:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:34:18 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.a0456a6fe3208890bcda6fc85a73bb8f@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: jberthold Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D83 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4ee8c27302e6bb3892e7c47a7111b0683d032c07/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4ee8c27302e6bb3892e7c47a7111b0683d032c07" use GHC-7.8.3's values for thread block reason (fixes #9333) Summary: For now, BlockedOnMVar and BlockedOnMVarRead are not distinguished. Making the distinction would mean to change an exported datatype (API change). Code for this change is included but commented out. The patch adds a test for the threadstatus, which retrieves status BlockedOnMVar for two threads blocked on writing and reading an MVar. Test Plan: ran validate, including the new test Reviewers: simonmar, austin, ezyang Reviewed By: austin, ezyang Subscribers: phaskell, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D83 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:34:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:34:19 -0000 Subject: [GHC] #9363: windows configure 'find invalid mode' In-Reply-To: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> References: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> Message-ID: <061.74801298751d5471ca77724b4e21f85e@haskell.org> #9363: windows configure 'find invalid mode' -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"003bcf20c20391fdd61789ba24269b0f508a3d2f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="003bcf20c20391fdd61789ba24269b0f508a3d2f" Do not check permissions when running find on Windows. Fixes #9363. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:34:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:34:19 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.13d91ea2e157aeba58b25fb9af6737ab@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------+------------------------------------------- Reporter: | Owner: configurator | Status: patch Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"8240312ae37a4a1cb89adf13289ac48d7e2aa1d8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8240312ae37a4a1cb89adf13289ac48d7e2aa1d8" driver: Fix usage of '$0' in ghcii.sh (#8873) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:34:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:34:19 -0000 Subject: [GHC] #9362: make clean deletes inplace mingw In-Reply-To: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> References: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> Message-ID: <061.947657dbe43eddd6dda877333b9d507d@haskell.org> #9362: make clean deletes inplace mingw -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b126ad3f59a62f91b2e2d92ec9d51d245861b655/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b126ad3f59a62f91b2e2d92ec9d51d245861b655" Don't clean away inplace/mingw and inplace/perl. Fixes #9362. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:49:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:49:44 -0000 Subject: [GHC] #9265: Create PackageKey to replace PackageId, including version dependency information (was: Extend PackageId to include version dependency information) In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.c7a3dc3899884266562a203793ac6574@haskell.org> #9265: Create PackageKey to replace PackageId, including version dependency information -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.9 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:54:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:54:14 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.a8dd8ed1cb8b5ba07569e4f3d219c050@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:54:31 -0000 Subject: [GHC] #9333: Thread status decoded wrong in base library In-Reply-To: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> References: <048.2abb9ad56d7571da5e2ab5df32352b9a@haskell.org> Message-ID: <063.a9b15b25fcafb77401739616b2b21920@haskell.org> #9333: Thread status decoded wrong in base library -------------------------------------+------------------------------------- Reporter: jberthold | Owner: jberthold Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D83 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:54:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:54:50 -0000 Subject: [GHC] #9362: make clean deletes inplace mingw In-Reply-To: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> References: <046.ead9ef37a86d4b8c9cf3a34a185e4326@haskell.org> Message-ID: <061.2c400bb06736d4922276cfbcea044773@haskell.org> #9362: make clean deletes inplace mingw -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:55:05 -0000 Subject: [GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory In-Reply-To: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> References: <051.c7c74d65a5ac5256959953ba2081bc0a@haskell.org> Message-ID: <066.41840d540c8b922c08be9f0cefb5edf0@haskell.org> #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------------+------------------------------------- Reporter: | Owner: configurator | Status: closed Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 14:55:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 14:55:23 -0000 Subject: [GHC] #9363: windows configure 'find invalid mode' In-Reply-To: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> References: <046.9777dc9401f5a3f009eb0eed195cbe78@haskell.org> Message-ID: <061.3ff94f80dcb2c6e77f44e41085c90b19@haskell.org> #9363: windows configure 'find invalid mode' -------------------------------------+------------------------------------- Reporter: niklasl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 15:34:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 15:34:28 -0000 Subject: [GHC] #9375: Support for module thinning/renaming on command line Message-ID: <045.7767d06b67f08763343ee12e2c8eb40a@haskell.org> #9375: Support for module thinning/renaming on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package "foo (A as B, C)"`. This feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping. Since this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated. In the **absence** of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT. **With** the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 15:35:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 15:35:41 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.56cbcd4c52bf641a938c086eb750ea66@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by diatchki): We can already mark individual instances as INCOHERENT. For example, in `Data.Typeable.Internal` we have an instance like this: {{{ instance {-# INCOHERENT #-} (Typeable f, Typeable a) => Typeable (f a) where ... }}} In the fourth bullet of the commit message (comment:16 above), I just meant that instances annotated with INCOHERENT work in the same way they did before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 16:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 16:29:26 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.82bcd1ad9d7f1b5ca4c99325cf1c6d0c@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.4 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by rwbarton): OK, then I expect this bug will disappear if and only if the user's libgmp is (the as-yet unreleased) 6.0.1 or newer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 17:43:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 17:43:16 -0000 Subject: [GHC] #9349: excessive inlining due to state hack (was: excessive inlining with -fpre-inlining) In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.a43784c6bba7653b53a8f49c5ba9602a@haskell.org> #9349: excessive inlining due to state hack -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Is this a show-stopper for anyone? No, I don't believe so. Should I close it as a duplicate of #1168? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 17:55:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 17:55:51 -0000 Subject: [GHC] #9349: excessive inlining due to state hack In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.69a31c905dc1f761d7acf23ecfa90a69@haskell.org> #9349: excessive inlining due to state hack -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by klao): I'd like to point out before we close this issue, that it is (at least in part) a `7.8`-specific regression. My little example works perfectly fine with `7.6.3` regardless of optimization levels and flags. So, in the least, it has become easier to trigger this bug (even if some similar instances were present before). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 18:00:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 18:00:07 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.eed77aa828e7945fd7d54709bfff9f76@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | nofib/spectral/calendar | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by klao): * cc: klao@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 21:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 21:47:22 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.09a5b6d450760b0192010e600e6750ab@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by k.gadek): Hi, Is there a plan for fixing this soon? We hit this bug on OS X (precisely the same thing as here: http://stackoverflow.com/questions/24796874/cant- install-diagrams-arithmoi-on-mac ? arithmoi now uses LLVM backened by default). My company's software can't be installed on Windows nor OS X because of this one and it's? well, ''quite problematic'', as our customers require the Windows version (and most probably OS X too). The workaround ? disabling LLVM ? is not possible since we use it (vide ''accelerate''). In other words: solving this is crucial for our company. Is it possible to fix it by 7.8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 21:55:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 21:55:11 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.332ab4f010636621c88a682a908cabdf@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dterei): * cc: dterei (added) * owner: dterei => Comment: I'm not going to have time to look at this soon sorry but hopefully someone else will. It's a build system / config issue anyway so not specific to LLVM knowledge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 22:03:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 22:03:49 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.e97da6a698cff4535e4bb546017b2696@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): artella, your observations seem correct to me. I am not sure, but I think that perhaps GHCi does not garbage collect CAFs, ever. Perhaps a feature request? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 23:37:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 23:37:13 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.83b8aa642da38dea2e3c205ab5826afd@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nfrisby): Hi Simon, Jan. Thanks for including my on these recent ticket comments. I apologize for the stagnant branch. I've merged a recent master into my local copy of the late-lam-lift branch. 1) I believe I've successfully completed the merge. There was one subtle bug that I recently caught though, so I'm concerned. 2) My push to origin/late-lam-lift is being rejected due to some submodule stuff I don't grok. I need to find the correct ghc-devs email with the right conjury in it. (I have also emailed Austin and hvr asking them to move the branch to the wip/ folder so it's less restricted.) 1 and 2 are done. The rest are my current plan, including longer-term things. 3) In light of the host of changes that got merged in, I'm developing the status notes from scratch. These are destined for a web page. The meat will focus on each flag (there are several), what it does, and why. Most of the flags are for developers/power-users only. 4) I will simplify/clean-up the code itself. 5) I will add tests for when the late lambda float is enabled. (Is the test-suite configurable for this sort of predicate?) After 3--5 are complete, someone else could pick-up the work. I hesitate to estimate a timeline because I'm moving across the country in the next week. My goal is by mid-August. 6) My partial paper draft is still on a borked laptop's hard drive. Once the code and notes are in a state where someone can pick them up, I'm going to move the paper back on to my todo list, but with less immediacy. If someone beats me to the write-up, I'll happily hand over what I have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 23:39:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 23:39:55 -0000 Subject: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.96b80924fc65b84e6a1a97b0db29b12a@haskell.org> #9279: Local wrapper function remains in final program; result = extra closure allocation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nfrisby): Regarding status of late lambda lift, please see ticket:9374#comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 28 23:49:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jul 2014 23:49:26 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.cc5e4920af569dc220bf6400253c7819@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): My Android cross-compiler (built with my fork https://github.com/rwbarton /ghc-android) produces the correct output `0.0\n1.0\n...100.0\n`. Can someone who sees the wrong output attach the object files `rts/dist/build/PrimOps.o`, `rts/dist/build/StgPrimFloat.o` to this ticket? (Or their disassemblies?particularly if they are not ELF object files.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 00:35:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 00:35:38 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.38492a978a335f414627de7092fa3656@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2258 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by iduhetonas): * owner: iduhetonas => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 01:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 01:28:01 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.ef288943d5204594afb013c63f73a0b0@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): When we do {{{ case ds1 of wild_XT { -- ds1 :: Double# (y = D# ds1) __DEFAULT -> ... 0.0 -> ... } }}} inside the `0.0` case we seem to create a local unfolding `ds1 = 0.0`. You can see this happening with `-dverbose-core2core -ddump-inlinings`: search for "Inlining done: x" or "ds1". This is wrong because the `0.0` case matches both positive and negative zero. That is the correct semantics that makes the Core match the original program, and it is implemented correctly by the code generation. But it means that we can't create this local unfolding when the pattern is specifically `0.0`. I don't know where this unfolding gets created, or I'd try to fix it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 01:58:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 01:58:50 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.287c9691b22a93840533298ffd779b90@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: strange-closure- Operating System: Linux | type Type of failure: Compile- | Architecture: x86_64 (amd64) time crash | Difficulty: Project (more Test Case: | than a week) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by rwbarton): Do you still see this issue with GHC 7.8.3? It will be rather hard to diagnose this without more information, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 03:16:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 03:16:43 -0000 Subject: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.739e207c0058d6042e4c39cfceb0ef06@haskell.org> #9279: Local wrapper function remains in final program; result = extra closure allocation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nfrisby): Based only on the eye-balled free variable analysis of $wa4, I think that the current late lambda lift implementation would lift $wa4. ipv7_X5Ne is the only free variable I see in the closure, so replacing $wa4 with ip7_X5Ne in a2_s6lH would not constitute closure growth, which is what would most likely prevent the lift. (I'm assuming $wa4 is not LNE.) I'll attempt the repro with my local build and let you know for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 03:25:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 03:25:34 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.e6f5f76e150e17b82b816f1bb4fb7f39@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nfrisby): There are several concepts in your quote from Max that are not familiar to me; I can't immediately predict much accurately about the late lambda float's interaction with SAT. I'd be happy to collaborate with anyone who would like to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 03:45:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 03:45:49 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.4918e4977d665d3e7bf708bb8c83e30e@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here is the disassembly of `stg_decodeFloatzuIntzh` from that build, annotated with my primitive understanding of ARM assembly. It's ... not right. {{{ 0000051c : 51c: e2450004 sub r0, r5, #4 ; r0 = Sp - 4 520: e2458008 sub r8, r5, #8 ; r8 = Sp - 8 -- r8 happens to be R2, but irrelevant for now 524: ed058a01 vstr s16, [r5, #-4] ; Sp[-4] = F1 -- Useless, and we haven't done the stack check yet! 528: e150000b cmp r0, fp 52c: 3a000007 bcc 550 ; if (Sp - 4 <= SpLim) goto gc; ; -- Not sure how it optimized Sp - 8 < SpLim to this, but looks correct. 530: eeb00a48 vmov.f32 s0, s16 ; s0 = F1 534: e1a01008 mov r1, r8 ; r1 = Sp - 8 ; -- At this point the args r0, r1, s0 are set up properly for the ccall. 538: ee187a10 vmov r7, s16 ; R1 = F1 ; -- Very odd! This is the only time we set R1, but it should be set to Sp[-4] ; -- after the ccall! 53c: ebfffffe bl 0 <__decodeFloat_Int> 53c: R_ARM_CALL __decodeFloat_Int ; ccall __decodeFloat_Int 540: e5988000 ldr r8, [r8] ; R2 = Sp[-8] -- good, but what about R1? 544: e5953000 ldr r3, [r5] ; r3 = Sp[0] -- return address 548: e12fff33 blx r3 54c: e12fff1e bx lr ; return to r3 (this sequence is odd but apparently harmless, and used everywhere) ; gc branch follows 550: e59f500c ldr r5, [pc, #12] ; 564 554: e5885000 str r5, [r8] 558: e1a05008 mov r5, r8 55c: ebfffffe bl 0 55c: R_ARM_CALL stg_gc_noregs 560: e12fff1e bx lr }}} May be a bug in GHC or LLVM. It would be nice to see the LLVM IR we output. What version of LLVM are you using, Ansible, amurrayc? I eyeballed the assembly for `__decodeFloat_Int` also and it appears correct at first glance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 05:58:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 05:58:19 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.49d3acba25d5a4a6b24f172476ed50bb@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: I think that something is reordering the assignment to R1 with the call to `__decodeFloat_Int`. After all, R1 is supposed to receive the value that ends up at `Sp[-4]`, which is set to F1 at the top of the function. Not sure whether GHC or LLVM is doing this incorrect reordering. It would be informative to * build the broken GHC * `rm rts/dist/build/PrimOps.o` * run `make` again and copy the command used to build `rts/dist/build/PrimOps.o` * rerun the command with `-v -keep-tmp-files -ddump-cmm -ddump-to-file` * find the files `rts/PrimOps.dump-cmm` and `/tmp/ghc*/ghc*.ll` and attach them to this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 06:19:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 06:19:27 -0000 Subject: [GHC] #9376: Recursive closed type families fails Message-ID: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> #9376: Recursive closed type families fails -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the following code, I am getting strange compiler errors that I suspect has to do with the recursive application of the OrdRec type family: {{{ import GHC.Prim import Data.Proxy import qualified Data.Set as Set type family OrdRec (f :: * -> *) a b :: Constraint where OrdRec f a (f b) = ( Ord a, Ord (f b), OrdRec f a b ) OrdRec f a b = ( Ord a, Ord b ) setmap :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b setmap f set = Set.map f set }}} GHC gives the error message: {{{ ClosedTypeFamilyRecursion.hs:11:16: Could not deduce (Ord b) arising from a use of ?Set.map? from the context (OrdRec Set.Set a b) bound by the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b at ClosedTypeFamilyRecursion.hs:10:11-66 Possible fix: add (Ord b) to the context of the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b In the expression: Set.map f set In an equation for ?setmap?: setmap f set = Set.map f set Failed, modules loaded: none. }}} If we modify the OrdRec type family to remove the recursive application: {{{ type family OrdRec (f :: * -> *) a b :: Constraint where OrdRec f a (f b) = ( Ord a, Ord (f b) ) OrdRec f a b = ( Ord a, Ord b ) }}} Then GHC is able to compile the file fine. What's extra weird, though, is that ghci appears to be able to evaluate the recursive type family correctly. If we comment out the setmap function, then load into ghci, we can verify that the OrdRec type family is giving the correct Ord constraints: {{{ ghci> :t Proxy :: Proxy (OrdRec [] Int Float) Proxy :: Proxy (OrdRec [] Int Float) :: Proxy (Ord Int, Ord Float) ghci> :t :t Proxy :: Proxy (OrdRec [] Int [Float]) Proxy :: Proxy (OrdRec [] Int [Float]) :: Proxy (Ord Int, Ord [Float], (Ord Int, Ord Float)) ghci> :t Proxy :: Proxy (OrdRec [] Int [[Float]]) Proxy :: Proxy (OrdRec [] Int [[Float]]) :: Proxy (Ord Int, Ord [[Float]], (Ord Int, Ord [Float], (Ord Int, Ord Float))) }}} But if I try to define the setmap function interactively in ghci, I get the same error message: {{{ ghci> > let setmap = (\f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b :39:25: Could not deduce (Ord b1) arising from a use of ?Set.map? from the context (OrdRec Set.Set a b) bound by the inferred type of setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b at :39:5-98 or from (OrdRec Set.Set a1 b1) bound by an expression type signature: (OrdRec Set.Set a1 b1) => (a1 -> b1) -> Set.Set a1 -> Set.Set b1 at :39:14-98 Possible fix: add (Ord b1) to the context of an expression type signature: (OrdRec Set.Set a1 b1) => (a1 -> b1) -> Set.Set a1 -> Set.Set b1 or the inferred type of setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b In the expression: Set.map f set In the expression: (\ f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b In an equation for ?setmap?: setmap = (\ f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 06:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 06:49:27 -0000 Subject: [GHC] #9349: excessive inlining due to state hack In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.876dfb78d046f66ca267c70c2d5c4593@haskell.org> #9349: excessive inlining due to state hack -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I have no idea why it's become easier to trigger, but it's definitely very sensitive to how much inlining is done. Although Trac lets you close as duplicate, I tend to leave these things open (but linked) to remind us that there are a cloud of related examples. Closed things tend to imply "no need to look at me any more". But we are inconsistent about this at the moment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 07:10:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 07:10:50 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.7c37191f5d2d03917b45d481a79a1698@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, simonmar (added) * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 07:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 07:15:08 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.8c72081dacacf778eafada7a998e4013@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Nick: mid August would be great! The surrounding documentation and explanation (even paper) is important. The job turned out to be trickier than I expected when you started. It took weeks to work out why a handful of programs were getting worse and to devise analysis/heuristics to avoid them. I don't want someone else to have to re-invent that knowledge, and it's very hard to reverse-engineer it from the code. Moreover, I remain hopeful that, once written down, someone may see a way to achieve the goal with less trickiness. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 07:23:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 07:23:21 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.8533130c353332bbb4832610992a6110@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I can tell you exactly where it's created: line 2107 of `Simplify.lhs` (in today's HEAD), in function `simplAlt`. However I'm suspicious of adding a special case for float/double here. Rather, I think we should prohibit using Core-language `case` expressions to scrutinise float/double, so that `case` (in Core) behaves in a simple, predictable way. Rather I think we should probably generate {{{ case eqDouble# ds1 0.0## of True -> ... False -> ... }}} (or, rather, today's unboxed-boolean version). Now the magic is confined to how `eqDouble#` is implemented, which is the proper place for it. Now Haskell source code does allow case expressions over floats, but that's just a question of fixing the desugarer. Does that make sense? Does anyone feel like taking this on? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 07:48:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 07:48:56 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.3dd80894887c356e2d37c40e1337e65d@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, let's see the `-ddump-cmm` for `PrimOps.cmm` please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 07:52:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 07:52:43 -0000 Subject: [GHC] #9376: Recursive closed type families fails In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.b62aa3f092cd2bd579dd5c89617a321a@haskell.org> #9376: Recursive closed type families fails -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure that GHC 7.8.2 compiles this (the non-recursive version)? {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies #-} module T9376 where import GHC.Prim import Data.Proxy import qualified Data.Set as Set type family OrdRec (f :: * -> *) a b :: Constraint where OrdRec f a (f b) = ( Ord a, Ord (f b), Ord (f b) ) OrdRec f a b = ( Ord a, Ord b ) setmap :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b setmap f set = Set.map f set }}} I get {{{ bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 bash$ ghc -c T9376.hs T9376.hs:13:16: Could not deduce (Ord b) arising from a use of ?Set.map? from the context (OrdRec Set.Set a b) bound by the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b at T9376.hs:12:11-66 Possible fix: add (Ord b) to the context of the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b In the expression: Set.map f set In an equation for ?setmap?: setmap f set = Set.map f set }}} And so it should! We can't simplify `OrdRec Set a b` to `(Ord a, Ord b)` because in some call to `setmap` you might instantiate `b` to an application. The paper on closed type families elaborates. I'm puzzled how you get the behaviour you describe. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 08:55:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 08:55:16 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.d85071c7fe9383d638512f01149c68af@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, thanks. As you say in comment:16, an instance can have just one of these four properties. But the rules in the user manual then don't seem quite right. They currently read thus (in my HEAD, somewhat improved from HEAD): {{{ The willingness to be overlapped or incoherent is a property of the instance declaration itself, controlled as follows: * An instance is overlappable if it has an OVERLAPPABLE or OVERLAPS pragama, or if the module in which the instance appears is compiled with -XOverlappingInstances. * An instance is overlapping if it has an OVERLAPPING or OVERLAPS pragama, or if the module in which the instance appears is compiled with -XOverlappingInstances. * An instance is incoherent if it has an INCOHERENT pragama, or if the module in which the instance appears is compiled with -XIncoherentInstances. Now suppose that, in some client module, we are searching for an instance of the target constraint (C ty1 .. tyn). The search works like this. * Find all instances I that match the target constraint; that is, the target constraint is a substitution instance of I. These instance declarations are the candidates. * Find all non-candidate instances that unify with the target constraint. Such non-candidates instances might match when the target constraint is further instantiated. If all of them are incoherent, proceed; if not, the search fails. * Eliminate any candidate IX for which both of the following hold: * There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable or IY is overlapping. * If only one candidate remains, pick it. Otherwise if all remaining candidates are incoherent, pick an arbitrary candidate. }}} As things stand, and in the implementation, INCOHERENT does not imply "overlappable" or "overlapping". And it probably should. After all, if you have two candidate instances {{{ (incoherent) C [a] (no pragma) C [Int] }}} you probably want to pick the latter not the former! The alternative (which I do not advocate) is to treat overlapping and incoherent as separate things, so you can say {{{ instance {-# INCOHERENT, OVERLAPPABLE #-} C [a] }}} So I suggest we change the spec above, and the impl to say {{{ * An instance is overlappable if it has an OVERLAPPABLE or OVERLAPS or INCOHERENT pragama, or if the module in which the instance appears is compiled with -XOverlappingInstances or -XIncoherentInstances. ...and similarly "overlapping" }}} Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 08:58:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 08:58:55 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.0c575ebece9e7bbcc126ecd224e023dc@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): One more thing. Look at this note in `InstEnv`: {{{ Note [Incoherent instances] ~~~~~~~~~~~~~~~~~~~~~~~~~~~ For some classes, the choice of a particular instance does not matter, any one is good. E.g. consider class D a b where { opD :: a -> b -> String } instance D Int b where ... instance D a Int where ... g (x::Int) = opD x x -- Wanted: D Int Int For such classes this should work (without having to add an "instance D Int Int", and using -XOverlappingInstances, which would then work). This is what -XIncoherentInstances is for: Telling GHC "I don't care which instance you use; if you can use one, use it." Should this logic only work when *all* candidates have the incoherent flag, or even when all but one have it? The right choice is the latter, which can be justified by comparing the behaviour with how -XIncoherentInstances worked when it was only about the unify-check (note [Overlapping instances]): Example: class C a b c where foo :: (a,b,c) instance C [a] b Int instance [incoherent] [Int] b c instance [incoherent] C a Int c Thanks to the incoherent flags, [Wanted] C [a] b Int works: Only instance one matches, the others just unify, but are marked incoherent. So I can write (foo :: ([a],b,Int)) :: ([Int], Int, Int). but if that works then I really want to be able to write foo :: ([Int], Int, Int) as well. Now all three instances from above match. None is more specific than another, so none is ruled out by the normal overlapping rules. One of them is not incoherent, but we still want this to compile. Hence the "all-but-one-logic". }}} That makes sense, but it doesn't implement the rule in the manual (comment:20). I think the last bullet should therefore read {{{ * If exactly one non-incoherent candidate remains, pick it. If all remaining candidates are incoherent, pick an arbitary one. Otherwise fail. }}} Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 09:00:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 09:00:14 -0000 Subject: [GHC] #9376: Recursive closed type families fails In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.bfb3ddfcfaa3dddfd3fc46b7f4d77a67@haskell.org> #9376: Recursive closed type families fails -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kosmikus): Replying to [comment:1 simonpj]: Simon, your non-recursive version says: > type family OrdRec (f :: * -> *) a b :: Constraint where > OrdRec f a (f b) = ( Ord a, Ord (f b), Ord (f b) ) > OrdRec f a b = ( Ord a, Ord b ) which indeed fails, but with > type family OrdRec (f :: * -> *) a b :: Constraint where > OrdRec f a (f b) = ( Ord a, Ord (f b) ) > OrdRec f a b = ( Ord a, Ord b ) it compiles. Does GHC somehow recognize that the first line is a special- case of the second? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 09:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 09:46:58 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.b3cc6b2b98bc7a0ecc00905a2e8fa0c2@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Sigh. One last observation. Read the Description of this ticket. I thought we'd end up with {{{ instance {-# INCOHERENT #-} Typeable (n::Nat) where ... instance (Typeable f, Typeable a) => Typeable (f a) where ... }}} The weird one is the `Typeable (n:Nat)` instance. Our reasoning is that we don't want to worry about instantiations of `n`. And this is what we wrote in the Description. But actually the rules above mean that we have to write this {{{ instance Typeable (n::Nat) where ... instance {-# INCOHERENT #-} (Typeable f, Typeable a) => Typeable (f a) where ... }}} (and that is indeed what is in `Data.Typeable.Internals` today. The incoherent flag is on the innocent `Typeable (f a)` declaration. Obviously incoherence is an area where we don't expect "right" answers. But the above does suggest that it could make sense to change the behaviour of incoherence, to this: ignoring a non-candidate unifying instance when (and only when) there is an incoherent matching instance. Here is another example to illustrate {{{ class C a where op :: a -> Bool instance {-# INCOHERENT? #-} C [a] where op x = True instance {-# INCOHERENT? #-} C [Int] where op x = False f :: [a] -> Bool f x = op x }}} Without incoherence, `f` is rejected even with overlapping instances, because the choice depends on the instantiation of `a`. So, which instance needs `{-# INCOHERENT #-}` to make it acceptable? Today the answer is the second one; with the change proposed here, it'd be the first one. I don't feel very strongly about this, but the `Typeable` example (which drove the entire thread!) is quite compelling to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 10:22:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 10:22:38 -0000 Subject: [GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ Message-ID: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | 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: Phab:D99 -------------------------------------+------------------------------------- During normal course of action in `real_main` a process is terminated with a call to {{{#!hs shutdownHaskellAndExit(exit_status, 0 /* !fastExit */); }}} which is defined as {{{#!hs void shutdownHaskellAndExit(int n, int fastExit) { if (!fastExit) { // even if hs_init_count > 1, we still want to shut down the RTS // and exit immediately (see #5402) hs_init_count = 1; // we're about to exit(), no need to wait for foreign calls to return. hs_exit_(rtsFalse); } stg_exit(n); } }}} However, when we call `forkProcess`, the child process does ''not'' terminate in this manner, but instead calls {{{#!hs hs_exit(); // clean up and exit stg_exit(EXIT_SUCCESS); }}} instead, where `hs_exit` is defined as {{{#!hs void hs_exit(void) { hs_exit_(rtsTrue); // be safe; this might be a DLL } }}} Crucially, this means that, unlike the parent, the child process ''does'' wait for foreign calls to be terminated (it calls `hs_exit_` with `rtsTrue` instead of `rtsFalse`). I don't see a reason why the child process should terminate in a different manner to the parent, so I propose to change this so that `forkProcess` calls `shutdownHaskellAndExit`, just like `real_main` does. Incidentally, this is the immediate cause for https://ghc.haskell.org/trac/ghc/ticket/9284 , although the patch proposed in this ticket is not sufficient to solve the problems with termination of the I/O manager in the general case (but I will let Andreas explain that in more detail :). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 10:37:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 10:37:11 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.9a0cc658e1707bd693bc020c5c608186@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edsko): * related: => 9377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 10:37:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 10:37:29 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.c9766d750fce56a3e088c236c3da454b@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edsko): * related: 9377 => #9377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 10:38:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 10:38:42 -0000 Subject: [GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ In-Reply-To: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> References: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> Message-ID: <059.b5eee0e4c54b9e33916ca37a0e9ea918@haskell.org> #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D99 | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 10:39:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 10:39:53 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.a06b0e9e4643dde52db8b0cf783916f5@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 11:14:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 11:14:28 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.9bd4cf8ae51dda96813e125134a23125@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Is it ok to remove the para about "non-parametric" equations? Re your question, no that `S` doesn't have a CUSK, any more than {{{ data T a b = MkT (T a b) a b }}} does. It's "obvious" that `S`'s RHS has kind `*`, but only because you have mentally done kind inference on `S`'s right hand side. Of course, the example you give would be accepted in fact. Neither has a CUSK, but normal inference and generalisation suffices. There is no polymorphic recursion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 11:48:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 11:48:00 -0000 Subject: [GHC] #9376: More informative error messages when closed type families fail to simplify (was: Recursive closed type families fails) In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.570f3e6a37cad584d890c4904407c787@haskell.org> #9376: More informative error messages when closed type families fail to simplify -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * type: bug => feature request Comment: The behavior seen here is as "expected", for a sufficiently nuanced expectation. I don't see an implementation bug here. Let's look at the two different definitions in play: {{{ type family OrdRec1 f a b where -- closed families do kind inference! OrdRec1 f a (f b) = (Ord a, Ord (f b), OrdRec1 f a b) OrdRec1 f a b = (Ord a, Ord b) type family OrdRec2 f a b where OrdRec2 f1 a1 (f1 b1) = (Ord a1, Ord (f1 b1)) OrdRec2 f2 a2 b2 = (Ord a2, Ord b2) }}} Let's try to simplify `OrdRec1 Set.Set a b`, for some universally- quantified `a` and `b`. The first equation of `OrdRec1` clearly doesn't apply, and the second equation doesn't clearly apply. What I mean here is that we don't know enough about `b`: if we later learn that `b` is `Set.Set Int`, then we really should have used the first equation. GHC will not commit to a later equation when there's a possibility of using an earlier one, if it learns more about the variables involved. So, GHC gives up and refuses to simplify. When testing with concrete types, as you have done in GHCi, `OrdRec1` works just fine, as then it can be quite sure of which equation to pick. But how does `OrdRec2` work? As kosmikus guesses, GHC notices that the two cases are, in the terminology of the paper, ''compatible''. Specifically, GHC looks at the LHSs and finds that they unify, under the substitution `[f2 |-> f1, a2 |-> a1, b2 |-> f1 b1]`. Then, GHC asks: will the RHSs then become the same under that substitution? In this case, the answer is '''yes''', so GHC marks the equations as ''compatible''. The benefit of compatibility is that GHC then isn't so sensitive about premature commitment among compatible equations. After all, if GHC chooses the second equation, but later learns that the first should be used, it wouldn't have gotten a different answer, as long as the equations are compatible. For better or worse, you can observe some of this reasoning in `OrdRec1` if you reorder either RHS. Even though constraint tuples are considered to be order-less sets, the compatibility algorithm doesn't know this, and if one of the RHSs is reordered, the compatibility check fails and GHC becomes more careful about committing to an equation during simplification. I'm going to leave this ticket open as a request for a better error message, as this issue comes up every so often, and I'd like not to have to answer it individually each time. I think that it should be possible to note when GHC is hesitant to commit to an equation and then suggest to a user to learn more about closed type families, with a helpful link. The error message, or perhaps a new facility in GHCI, might also point out the compatibility relationships among equations, as these relationships are sometimes key to understanding a closed type family's behavior and are sometimes non-trivial for a human to derive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 12:02:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 12:02:41 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.d84f9b84249264ac923a5b4e8a662cf4@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Simon's comment:20 and comment:21. I think those changes are for the better. As to comment:22, it sounds like you wish to distinguish between `INCOHERENTABLE` and `INCOHERENTING`. (I don't want to use those names, just draw the parallel to the `OVERLAP` pragmas.) Is this a reasonable interpretation of what you're saying? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 12:09:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 12:09:31 -0000 Subject: [GHC] #9376: More informative error messages when closed type families fail to simplify In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.60e89ef08bb28ca2914d0858a15d2712@haskell.org> #9376: More informative error messages when closed type families fail to simplify -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Is the test for rhss-unify important? How bad would it be if the compatibility check ignored the RHS? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 12:15:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 12:15:46 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.65359c03df8e0ce8166d7fdaa8a36124@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:23 goldfire]: > As to comment:22, it sounds like you wish to distinguish between `INCOHERENTABLE` and `INCOHERENTING`. (I don't want to use those names, just draw the parallel to the `OVERLAP` pragmas.) Is this a reasonable interpretation of what you're saying? Yes, but I ''really'' don't want to actually have that complexity. Obvious alternatives: * Current behaviour: INCOHERENT means INCOHERNTING * Behaviour proposed in comment:22: INCOHERENT means INCOHERENTABLE * Another alternative: INCOHERENT means both INCOHERENTING and INCOHERENTABLE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 12:17:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 12:17:21 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error Message-ID: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, if I say `{-# LANGUAGE Foo #-}` at the top of my file, it fails to compile. This failure seems unnecessary, especially because any new language feature `Foo` enables will fail to compile later on down the file. Is it possible to have a "stern warning" that is produced even when other parts of the file produce errors? The reason I'm bringing this up is that, when 7.8 came out with its role annotations, users needed CPP in two different places: both to protect the `RoleAnnotations` pragma and to protect the role annotations themselves. This may be unavoidable on the role annotations directly, but I think we can improve the situation around `LANGUAGE` pragmas. Is there a downside to this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:08:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:08:33 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.2c26a14c18c3bbb590c468856650716f@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by k.gadek): For the record: I reinstalled LLVM on my system using ''brew'' with additional flags (notably ''--with-clang'') and now it all appears to work. Anyway, OS X by default is not able to build anything with `-fllvm` so despite the blame on Apple for doing this weird LLVM-mockery, I think this should be anticipated in some way; at least some note around download section, or ? even better ? give more meaningful error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:32:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:32:41 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.249b06b0a67724a2bb7a9e4de1f8ae61@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): I think you will also need to add `-keep-llvm-files` to the command line as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:36:43 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.c84faf91d0e91dfd94ab4cf659c6297e@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Fyi, when you inform Cabal about the used language pragmas via `other- extensions` (which then still need to be declared on a per-module basis via pragmas), Cabal will refuse to build the project if your compiler doesn't provide all those extensions. Moreover, there is tooling to generate the `other-extensions` list automatically from the `.hs` files making up a build-target. So I'm a bit sceptical changing the semantics of `LANGUAGE` to be a mere warning would interact badly with the Cabal tooling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:45:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:45:40 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.0c068f7b85bfa82cf9fa9f0ed5475534@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. [wiki:GhcKinds/KindInference wiki page] updated, including type synonym CUSKs as described. I still find that a little wonky, but just in the concrete syntax, not the semantics. For what it's worth, my example in comment:34 does seem to require at least one CUSK -- at least, it does in 7.8. In any case, I think we're in agreement here about what to do, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:48:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:48:01 -0000 Subject: [GHC] #9376: More informative error messages when closed type families fail to simplify In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.0cdf67de5c93970e2781b4595d6c752f@haskell.org> #9376: More informative error messages when closed type families fail to simplify -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:4 simonpj]: > Is the test for rhss-unify important? How bad would it be if the compatibility check ignored the RHS? The crux of compatibility is that the RHSs unify under the substitution. Without that check, what would compatibility mean? Or, do I misunderstand your question? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:57:45 -0000 Subject: [GHC] #9376: More informative error messages when closed type families fail to simplify In-Reply-To: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> References: <050.e5feedd4687f07c7f2d97ba58987526b@haskell.org> Message-ID: <065.3e4bae582a70e9584dca0fe7d5a6fa62@haskell.org> #9376: More informative error messages when closed type families fail to simplify -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple (Type checker) | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): To get the desired behavior in the original program you should help GHC out a little by factoring out the common part of the two constraints. {{{ type OrdRec (f :: * -> *) a b = ( Ord a, Ord b, OrdRec' f a b ) type family OrdRec' (f :: * -> *) a b :: Constraint where OrdRec' f a (f b) = OrdRec f a b OrdRec' f a b = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 13:58:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 13:58:11 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.f4637341bbdea90b22bedc577ba9cf2d@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a good observation, but I don't think it blocks the original request. If I understand correctly, if unrecognized `LANGUAGE` pragmas are a warning, then Cabal might refuse to build something that would, in fact, compile. This doesn't seem deadly. In packages I've released, I've (rightly or wrongly) not specified any extensions in the cabal file. (Except for `TemplateHaskell`, which I understand is necessary for other reasons.) Admittedly, now that you've made me aware of the undocumented `other-extensions` entry, I might change my practice to indeed list the extensions. But, if I'm releasing a package that should compile under multiple GHCs, I would either protect the extension entry in the .cabal file or just omit that particular extension. It is still much easier to put a conditional in one place in a .cabal file than in every source file. Of course, one could list the extension of interest in `default-extensions` and omit it from the files, but then that has poor interaction with GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 14:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 14:03:05 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.11de5e80b2169d85d8923573d68ee7a5@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Well, then there's the other thing that turning such a pragma into warning is in conflict with the [https://www.haskell.org/onlinereport/haskell2010/haskellch12.html#x19-19100012.3 Haskell 2010 Report] stating explicitly that: > If a Haskell implementation does not recognize or support a particular language feature that a source file requests (or cannot support the combination of language features requested), any attempt to compile or otherwise use that file with that Haskell implementation **must fail with an error**. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 14:05:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 14:05:57 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.1a87f2ec26c134621b2bd2e8370234cb@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for finding that reference. I'm a big proponent of adhering to published standards, so that definitely cuts my proposal down a notch. Perhaps we could have a `-fallow-unrecognized-extensions`, or perhaps it's not worth the bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 14:10:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 14:10:03 -0000 Subject: [GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ In-Reply-To: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> References: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> Message-ID: <059.e9c600ae29dc3909aa5108cab3e3db8c@haskell.org> #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D99 | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 14:10:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 14:10:10 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.40e6d42db5c496ad564a989152aa2967@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, I don't see any harm in implementing and documenting an `-fallow- unrecognized-extensions` extension :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 14:22:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 14:22:47 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.e674cfcb7ab8f850ebde1939bd9d5bd0@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Ansible): I was just trying to determine the version of LLVM on my PI, and found a lot of files with "3.0" in the name. So I'm guessing version 3.0. The process of searching for the files resulted in a 'kernel journaling error' of some sort, IIRC, and now the thing won't boot. If more specific version information is needed let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 16:04:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 16:04:56 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.e25675aaef76cba83b5f241b78706c85@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @k.gadek for your use case, can't you do ` --ghc-options="-fasm"` ? Which accelerate package aside from accelerate-llvm (which is still prerelease quality last I checked) actually uses llvm? All the other (aside from the interpreted mode) do runtime compilation using the opencl/cuda ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 16:06:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 16:06:47 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.00ac10ca2d28355e27e353983842f064@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know whether this is the actual problem, but I think our TBAA is going wrong on this code. I tried to build GHC for Android with `-march=armv6`, so that it would use the floating point registers `s16` and so on. The build didn't finish for other reasons, but it got far enough to build `PrimOps.cmm`. Here is the `-ddump-cmm`: {{{ ==================== Post CPS Cmm ==================== [...] stg_decodeFloatzuIntzh() // [F1] { info_tbl: [] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4w: F32[Sp - 4] = F1; Sp = Sp - 8; call block_c4o_info() args: 0, res: 0, upd: 0; } }, block_c4o_entry() // [] { info_tbl: [(c4o, label: block_c4o_info rep:StackRep [True])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4o: if ((Sp + 4) < SpLim) goto c4q; else goto c4r; c4q: I32[Sp] = block_c4o_info; call stg_gc_noregs() args: 4, res: 4, upd: 4; c4r: _c4k::I32 = Sp + 4; call "ccall" arg hints: [PtrHint, PtrHint,] result hints: [] __decodeFloat_Int(_c4k::I32, Sp, F32[Sp + 4]); R2 = I32[Sp]; R1 = I32[_c4k::I32]; Sp = Sp + 8; call (P32[Sp])(R2, R1) args: 4, res: 0, upd: 4; } }, }}} What's unusual about this is that R1 is read by dereferencing the variable `_c4k`, even though the address it points to lives on the stack. This violates the assumptions made by our TBAA: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation And indeed, in the `.ll` file, the read of R2 is done using the "stack" type, but the read of R1 is done using the "other" type, which supposedly cannot alias the "stack" type. However, while it seems potentially relevant, I don't see specifically how this could cause our problem. (And my LLVM produced the correct assembly for `stg_decodeFloatzuIntzh`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 16:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 16:08:32 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.7049cfb3c04b6889920a4cc6b2b7fdee@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 16:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 16:51:54 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.f6f55a3eb1ac1c6f76db832e326d0f17@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by amurrayc): Replying to [comment:9 rwbarton]: As per the warning on https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I am using LLVM 3.0 binaries from http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz I can try recompiling with 3.5. Would it still be useful to have the -ddump-cmm? I just got back to my computer after a few days away but I could easily do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 16:55:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 16:55:16 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.f4edf6f1459dce39f9bef054f432ca20@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:16 amurrayc]: > Replying to [comment:9 rwbarton]: > > As per the warning on https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I am using LLVM 3.0 binaries from http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz > > I can try recompiling with 3.5. Would it still be useful to have the -ddump-cmm? I just got back to my computer after a few days away but I could easily do that. Let's figure out whether this is a bug in GHC or LLVM before we change any variables like the version of LLVM. I think LLVM 3.5 won't work with GHC 7.8 anyways. (Ben?) Yes, the -ddump-cmm output would still be useful. If you still have your built ghc tree, then you can follow the steps I listed above, skipping the first step. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 17:23:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 17:23:59 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.3a201104cdf181216c420ee977806c86@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by amurrayc): Replying to [comment:17 rwbarton]: Okay, I attached them. Hope that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 17:27:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 17:27:57 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.4cfa515b49344214fecc0a89311d4e75@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Thanks. Actually, for completeness, can you attach your `rts/dist/build/PrimOps.o` too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 17:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 17:31:14 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.d2210ccce2751b821146bc4067897149@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by amurrayc): Replying to [comment:19 rwbarton]: > Thanks. Actually, for completeness, can you attach your `rts/dist/build/PrimOps.o` too? Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 17:36:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 17:36:38 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.38965e76f97ca49efad6f4420c9493b5@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:17 rwbarton]: > Let's figure out whether this is a bug in GHC or LLVM before we change any variables like the version of LLVM. I think LLVM 3.5 won't work with GHC 7.8 anyways. (Ben?) > Indeed LLVM 3.5 disagrees with the aliases that the LLVM backend produces (in all GHC versions as far as I know). This is being tracked in #9142 where you'll find a patch that I threw together to rework the LLVM code generator to comply with LLVM's new restrictions on alias usage. The patch works with LLVM 3.4 and should work for 3.5 although I'm still waiting for the build to finish to verify this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 18:47:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 18:47:42 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.12d7544244d3e01a2035e1616ba3cdb1@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): For the record, here's the commit that failed to use the proper ticket- reference syntax: f510c7cac5b2e9afe0ebde2766a671c59137f3cc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 19:50:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 19:50:06 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. In-Reply-To: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> References: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> Message-ID: <062.7cba04e3a779eb1a82f801c2282cd594@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * version: 7.7 => 7.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 20:49:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 20:49:06 -0000 Subject: [GHC] #9200: Milner-Mycroft failure at the kind level In-Reply-To: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> References: <045.28ba8cd76492ba32136ed5e72991fd66@haskell.org> Message-ID: <060.4b1f38e33783df10a83010f13cf77d07@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think we're in agreement. Over to you when you have a moment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 21:00:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 21:00:54 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.d411b31b7a36517625bfadc742e1168a@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Indeed something seems to be going wrong in the simplifier when invoking ghc with -j4. {{{ *** Checking old interface for xmlhtml-0.2.3.2:Text.XmlHtml.HTML.Meta: [ 1 of 10] Compiling Text.XmlHtml.HTML.Meta ( src/Text/XmlHtml/HTML/Meta.hs, dist/build/Text/XmlHtml/HTML/Meta.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 26,260, types: 20,021, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,446,658, types: 953,432, coercions: 314,352} ... }}} With `-ddump-inlinings` I see this repeated over and over, which is not present with `-j1`: {{{ Inlining done: Data.String.fromString Inlining done: Data.Text.$fIsStringText Inlining done: Data.Text.pack Inlining done: Data.Text.Internal.Fusion.unstream Inlining done: Data.Text.Internal.Fusion.Common.map Inlining done: Data.Text.Internal.Fusion.Common.streamList Inlining done: Data.Text.Internal.safe Inlining done: Data.Bits.$fBitsInt_$c.&. Inlining done: Data.Text.Internal.Fusion.Types.$WYield [ repeats ~4000 times ] }}} According to `-ddump-inlinings -dverbose-core2core`, GHC never even considered inlining `fromString` with `-j1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 21:04:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 21:04:57 -0000 Subject: [GHC] #9318: Type error reported in wrong place with repeated type family expressions In-Reply-To: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> References: <047.204c85195b038b332a2aaa45854c7fa1@haskell.org> Message-ID: <062.84d406e0fea907cd3e43e22f2f2219a5@haskell.org> #9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): flat-skol-patch does actually work, but I don't think it's the right way to do it. The idea is more or less as in comment:1. I'm just capturing it so I don't lose it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 21:10:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 21:10:04 -0000 Subject: [GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.23f189fc949f5b27fff0b864fe784030@haskell.org> #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): That's bizarre. I can't think why the the simplifier would do ''anything'' different with `-j1` vs `-j4`! I'm hard pressed even to see where to start. Is it possible to determine when the log files start to differ? They should be identical except for the uniques (which you can suppress with `-dsuppress-uniques`). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 22:02:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 22:02:25 -0000 Subject: [GHC] #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel (was: large blowup in memory usage and time when doing parallel build of xmlhtml package) In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.028fa2d4f28066a74a389514624d7b3c@haskell.org> #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, the cause is hiding in plain sight, on the first line of `Text.XmlHtml.HTML.Meta`: {{{ {-# OPTIONS_GHC -O0 -fno-case-merge -fno-strictness -fno-cse #-} }}} If I add the same line to the start of the nine other modules in the package, then `Text.XmlHtml.HTML.Meta` compiles as quickly with `-j4` as with `-j1`. So somehow flags set by `OPTIONS_GHC` pragmas (or in this case, their absence) are leaking between different modules being built in parallel. These are all dynamic flags at least, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 22:33:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 22:33:05 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.53495464d4cde3ca2dfb67bf11996601@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonpj): OK I agree that the same issue arises if `IdentityT` was a data type, so my point about newtype unwrapping for `IdentityT` was a bit of a red herring. And yes I agree that this "silly example" is indeed a case where eta- reduction of newtype axioms (and data/newtype instance!) axioms is useful. And since the code is implemented, I suppose that the shortest path is to fix the conflict detector. But it does hurt me that we have NO formalised description of the eta- reduction story in any of our papers. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 22:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 22:42:50 -0000 Subject: [GHC] #9379: Blocked STM transaction is not interruptible Message-ID: <048.943534b67221dbed25ba3c1c69579c2c@haskell.org> #9379: Blocked STM transaction is not interruptible -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------+------------------------------------- {{{#!hs import Control.Exception import Control.Concurrent import Control.Concurrent.STM import Foreign.StablePtr main :: IO () main = do tv <- atomically $ newTVar True _ <- newStablePtr tv t <- mask_ $ forkIO (blockSTM tv) killThread t blockSTM :: TVar Bool -> IO () blockSTM tv = do atomically $ do v <- readTVar tv check $ not v }}} This code blocks forever. As I understand it, since the transaction blocks, it should be interruptible even despite the mask, and so killThread must succeed here, and the program should finish promptly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 22:44:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 22:44:13 -0000 Subject: [GHC] #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.f3faddb02467229967731b4707537b82@haskell.org> #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Brilliant work! I have no idea about how the leakage is taking place... that will need someone who knows how the `-j` stuff works in GHC. But I ''am'' puzzled by the `OPTIONS_GHC` flags in `Text.XmlHtml.HTML.Meta`. That pretty much switches off all optimisation in GHC, and you should need a jolly good reason do to that. Indeed, the necessity of doing so signals either a bug in GHC, or else some bad rewrite rules that go into a loop. It would be good to know which. Is the `OPTIONS_GHC` stuff accompanied with a prominent comment to explain such a bizarre options line? If not, would someone care to investigate? (All this is separate from the flag leakage question, of course.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 29 22:58:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jul 2014 22:58:24 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.ebd953db4042226e478ef92384bbcf66@haskell.org> #9371: Overlapping type families, segafult ----------------------------------------+---------------------------------- Reporter: pingu | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Changes (by simonpj): * owner: => goldfire Comment: So, to be concrete, Richard might you do this? It's not clear that two equations conflict just because their LHSs differ. Eg {{{ F x = Maybe F x Int = Maybe Int }}} But it's certainly safe to say "there's a conflict", and in fact the lengths only differ for data families in which case each RHS is a fresh data type. This is somewhat urgent because what we have now is actually unsound. If you can't do it, yell, and I will. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 06:53:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 06:53:43 -0000 Subject: [GHC] #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.707c5e342dd71b8694fc77cd806aa940@haskell.org> #9370: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: parmake Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 #9221 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => highest Comment: This sounds kinda serious -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:02:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:02:48 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.c380cd6f2f7e79079b2698a209c0ce09@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:04:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:04:00 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.da1dba85c4ef2b04a0ac5f54f7cea526@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:05:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:05:22 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.aa8a646885dbfb5139b320ce27673999@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 5144 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms * owner: => cactus * component: Compiler => Compiler (Type checker) * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:09:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:09:19 -0000 Subject: [GHC] #8968: Type signatures for pattern synonyms In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.30103ceb90a3c27fcba047b53481d632@haskell.org> #8968: Type signatures for pattern synonyms -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 8584 Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * blockedby: => 8584 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:10:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:10:34 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs (was: Type signatures for pattern synonyms) In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.c4cbdb64fb80ab5b1bfe76fdc6cd1f26@haskell.org> #8968: Pattern synonyms and GADTs -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 (Type checker) | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8584 Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:11:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:11:24 -0000 Subject: [GHC] #9226: Internal error when using equality constraint in pattern synonyms In-Reply-To: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> References: <051.9ff7e888b2f688be0dafb9aefbac40b9@haskell.org> Message-ID: <066.0629aeb09536ee663c935a1a8fedf0d5@haskell.org> #9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: closed Type: bug | Milestone: Priority: lowest | Version: 7.8.2 Component: Compiler | Keywords: renamer, pattern Resolution: duplicate | synonyms, GADTs Operating System: Linux | Architecture: x86 Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: | Related Tickets: #8968 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 08:37:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 08:37:15 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code Message-ID: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | 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: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC generates a wrong code for the case-match on GADT with polymorphic type, here is a minimal example attached, expected results are 'A' in all test cases (this is case for ghc-HEAD), however in: test0 - result is missing as matches are removed from code (according to core) test1 - returns A as expected test2 - output 'o_O' without any checks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 11:45:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 11:45:46 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.aa3df7590a917508fb8684cbc370f970@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => infoneeded Comment: As you note, this is working in HEAD. Is this ticket a request to make sure that the fix goes into 7.8.4, if that were to exist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 11:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 11:53:22 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.b9366ea5a60c674200c4195ca44135d9@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by qnikst): There are few reasons for this report: 1. Verify that this is a really wrong behaviour 2. Make sure that fix will go into 7.8.4 if it will ever be 3. Understand if it worth adding a regression test for the HEAD, in order track that behaviour will be correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 13:29:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 13:29:43 -0000 Subject: [GHC] #9381: Implement rdynamic Message-ID: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> #9381: Implement rdynamic -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: feature request | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Difficulty: Unknown | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 7015 | None/Unknown | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently ghc ignores the `-rdynamic` flag. With a small effort it can be used as a synonym of `-optl -rdynamic` in linux and `-optl -export-all-symbols` in windows/mingw32. In other platforms, similar translations must be possible to get the symbols of an executable exported. This feature would improve usability of an upcoming implementation of #7015. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 13:30:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 13:30:29 -0000 Subject: [GHC] #9381: Implement -rdynamic (was: Implement rdynamic) In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.72496b252d25d1384907a5bdca54cdfb@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 7015 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:02:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:02:55 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.dc58258d82852cf783b29c48f135be38@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 7015 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D102 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: => Phab:D102 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:14:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:14:13 -0000 Subject: [GHC] #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. Message-ID: <056.97e9a0a4c13ed7b2168e95c3c4ad018f@haskell.org> #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Windows Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9381 #7015 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In windows, the function `lookupSymbol` in `Linker.c` does not look for symbols exported in the executable. Thus, when a program is linked with `-optl -export-all-symbols`, the function `lookupSymbol` still fails to find them. Fixing this would improve the usability of `-rdynamic` (#9381) and an upcoming implementation for #7015. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:14:48 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.1ef25ad44e943e277197650d6b67fd77@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 7015 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D102 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * version: 7.8.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:20:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:20:17 -0000 Subject: [GHC] #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. In-Reply-To: <056.97e9a0a4c13ed7b2168e95c3c4ad018f@haskell.org> References: <056.97e9a0a4c13ed7b2168e95c3c4ad018f@haskell.org> Message-ID: <071.95ec4342e9f5be5322d6030343376023@haskell.org> #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9381 #7015 Test Case: | Blocking: | Differential Revisions: Phab:D103 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: => Phab:D103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:26:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:26:25 -0000 Subject: [GHC] #9383: GHCi parser doesn't properly handle -fobject-code Message-ID: <047.e6dcdb9c92c2dfd5d3c445e82b3f94d0@haskell.org> #9383: GHCi parser doesn't properly handle -fobject-code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- My complete Haskell source: module Foo where f x = x Shell: $ ghci Foo.hs -fobject-code GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. target ?-fobject-code? is not a module name or a source file Ok, modules loaded: Linker. Prelude Linker> Despite the wanring/error, GHCi *does* generate the object code. This error also prints when I *load* the compiled Foo object file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:29:53 -0000 Subject: [GHC] #9383: GHCi parser doesn't properly handle -fobject-code In-Reply-To: <047.e6dcdb9c92c2dfd5d3c445e82b3f94d0@haskell.org> References: <047.e6dcdb9c92c2dfd5d3c445e82b3f94d0@haskell.org> Message-ID: <062.5dcdf0764fb7850de4cc262ddc3c138a@haskell.org> #9383: GHCi parser doesn't properly handle -fobject-code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:45:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:45:46 -0000 Subject: [GHC] #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. In-Reply-To: <056.97e9a0a4c13ed7b2168e95c3c4ad018f@haskell.org> References: <056.97e9a0a4c13ed7b2168e95c3c4ad018f@haskell.org> Message-ID: <071.39bd86cc5c765261b7927a6fe807b7a9@haskell.org> #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: patch Type: bug | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9381 #7015 Test Case: | Blocking: | Differential Revisions: Phab:D103 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 14:46:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 14:46:26 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.9881c494c6eb241dc25e48a5c616a5c3@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: patch Type: feature | Milestone: request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 7015 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D102 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 15:27:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 15:27:03 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events Message-ID: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The problem was found when i tried to eventlog '''ghc --make''' itself. I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37 Here is small program to reliably reproduce the bug: {{{#!hs module Main where import qualified Data.List as L import qualified System.Environment as E import Control.Monad import qualified Control.Concurrent as CC import qualified Control.Concurrent.MVar as CC slow_and_silly :: Int -> IO Int slow_and_silly i = return $ length $ L.foldl' (\a v -> a ++ [v]) [] [1..i] -- build as: -- $ ghc --make a -O2 -threaded -eventlog -- valid eventlog: -- $ ./a 2 7000 +RTS -ls -N2 -- $ ghc-events validate threads a.eventlog -- Valid eventlog: -- ... -- invalid eventlog -- $ ./a 2 7000 +RTS -ls -- $ ghc-events validate threads a.eventlog -- Invalid eventlog: -- ... main = do [caps, count] <- E.getArgs let n_caps :: Int n_caps = read caps max_n :: Int max_n = read count CC.setNumCapabilities n_caps waits <- replicateM n_caps $ CC.newEmptyMVar forM_ waits $ \w -> CC.forkIO $ do slow_and_silly max_n >>= print CC.putMVar w () forM_ waits $ \w -> CC.takeMVar w }}} How to reproduce (comments have '''ghc-events''' version): {{{ $ ghc --make a -O2 -threaded -eventlog $ ./a 2 7000 +RTS -ls -N2 $ threadscope a.eventlog # works $ ./a 2 7000 +RTS -ls $ threadscope a.eventlog # crashes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 15:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 15:56:09 -0000 Subject: [GHC] #9385: Additions to Control.Monad Message-ID: <042.43d25471e6c4c7993c2ad33f337aca33@haskell.org> #9385: Additions to Control.Monad -------------------------------------+------------------------------------- Reporter: olf | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'd like to propose the following additions/changes to Control.Monad: `mfilter` can be generalised: {{{#!hs gen_mfilter :: Monad m => (a -> m ()) -> m a -> m a gen_mfilter f ma = (\a -> liftM (const a) (f a)) =<< ma }}} Now we obtain the old `mfilter` as {{{#!hs gen_mfilter.(guard.) }}} Further, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way: {{{#!hs mtimes :: Monad m => m () -> m a -> m a mtimes = gen_mfilter.const = liftM2 (flip const) when = mtimes.guard }}} For example, each element of a list can be duplicated like this: {{{#!hs mtimes [(),()] }}} To see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`. Another example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 16:01:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 16:01:38 -0000 Subject: [GHC] #9386: GHCi cannot load .so in same ./ Message-ID: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> #9386: GHCi cannot load .so in same ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) mylib.so ... failed. : user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 16:01:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 16:01:57 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ (was: GHCi cannot load .so in same ./) In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.6a433d6a6931c515e1c7a7983864213d@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 16:06:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 16:06:13 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.aaa2f96fa058d5aa81ce0a019d75d409@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > In my directory ./ I have an empty file Foo.hs and a shared object file > mylib.so. From that directory in the shell, > > $ ghci Foo *.so > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading object (dynamic) mylib.so ... failed. > : user specified .o/.so/.DLL could not be loaded > (mylib.so: cannot open shared object file: No such file or directory) > Whilst trying to load: (dynamic) mylib.so > Additional directories searched: (none) > > It's interesting that GHCi searches ./ and identifies the correct object > file, but then fails to load it. I have also tried the path ./*.so for > the GHCi option. > > However, if I move mylib.so to a directory ./Temp, > > $ ghci Foo Temp/*.so > > loads without issue. New description: In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) mylib.so ... failed. : user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so, mylib.so and ./mylib.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 16:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 16:11:27 -0000 Subject: [GHC] #9385: Additions to Control.Monad In-Reply-To: <042.43d25471e6c4c7993c2ad33f337aca33@haskell.org> References: <042.43d25471e6c4c7993c2ad33f337aca33@haskell.org> Message-ID: <057.4587e017d927dddfcecea4ca3bfa7015@haskell.org> #9385: Additions to Control.Monad -------------------------------------+------------------------------------- Reporter: olf | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.2 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): This sort of proposal should go through the libraries at haskell.org mailing list rather than the GHC Trac. Please feel free to submit this for discussion there to invite wider discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 16:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 16:48:59 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module (was: OPTIONS_GHC (or its absence) leaks between modules compiled in parallel) In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.820c62f3da76b1ead9ac38333ad40fb1@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: parmake => * priority: highest => high * related: #910 #9221 => Comment: OK I take it all back. The parallel build is not really responsible at all. You get the same blowup when building `Text.XmlHtml.HTML.Meta` with `-j1` if you just add an `import Text.XmlHtml.Common` so that `Text.XmlHtml.Common` is built before `Text.XmlHtml.HTML.Meta`. As far as I can tell, the reason is that when we read an interface file from an external package, we may or may not attach unfolding info to its Ids according to the dynamic flags that are in effect for the module we are building. But when we later build another module, we might reuse that external package information even though different dynamic flags are now in effect. I haven't tried to track down the code that loads interface files, but does this sound plausible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:07:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:07:03 -0000 Subject: [GHC] #8573: "evacuate: strange closure type 0" when creating large array In-Reply-To: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> References: <042.f5cd7a98abbf8cf5e70fa72eb7020fdc@haskell.org> Message-ID: <057.6774e3185411ee5f1a7d08d9afdb1dd9@haskell.org> #8573: "evacuate: strange closure type 0" when creating large array ----------------------------------------+---------------------------- Reporter: nad | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: Thanks for the report, I had this in my mental list of integer overflows to fix but hadn't created a ticket. Specifically, `stg_newArrayzh` (and all the other `new*Array` primops) need bounds-checking. Also see #229, but I regard that ticket as about integer overflows in the `array` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:07:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:07:50 -0000 Subject: [GHC] #8438: Validation failure compiling primitive-memops.c In-Reply-To: <047.531102d80c106049f501fc03b8c458e2@haskell.org> References: <047.531102d80c106049f501fc03b8c458e2@haskell.org> Message-ID: <062.7d13d5359472db177a6bfb17c4b5e1b6@haskell.org> #8438: Validation failure compiling primitive-memops.c -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): So, did this go away, or what? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:24:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:24:09 -0000 Subject: [GHC] #1620: ModBreaks.modBreaks_array not initialised (was: Bug in debugger 6.7.20070817) In-Reply-To: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> References: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> Message-ID: <059.7c525a6f2c78e09cd5c667d000738c62@haskell.org> #1620: ModBreaks.modBreaks_array not initialised -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * version: 6.7 => 7.8.3 * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:34:36 -0000 Subject: [GHC] #9387: LLVM backend: redundant code for functions calling themselves Message-ID: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> #9387: LLVM backend: redundant code for functions calling themselves -----------------------------------+--------------------------------------- Reporter: jmoy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+--------------------------------------- It seems that the LLVM backed does not recognize when a function calls itself. As a result it generates redundant load and store instructions. I am compiling the following simple recursive Fibonacci function {{{ fib::Int->Int fib n = loop n 0 1 where loop !n !a !b = if n==1 then a else loop (n-1) b (a+b) }}} I am attaching the files produced by {{{ ghc -c -O3 -fllvm -ddump-stg -ddump-cmm -ddump-llvm -ddump-to-file Fib.hs }}} I rename the generated LLVM file with a `.ll` extension and run `llc -O3` on it to generate the attached `.s` file (LLVM version 3.4.2). The actual work gets done in `Fib_zdwloop_info`. It begins as: {{{ Fib_zdwloop_info: # @Fib_zdwloop_info # BB#0: # %css pushq %rax movq %r13, (%rsp) movq %rbp, -8(%rsp) movq %r12, -16(%rsp) movq %rbx, -24(%rsp) movq %r14, -32(%rsp) movq %rsi, -40(%rsp) movq %rdi, -48(%rsp) movq %r8, -56(%rsp) movq %r9, -64(%rsp) movq %r15, -72(%rsp) movss %xmm1, -76(%rsp) movss %xmm2, -80(%rsp) movss %xmm3, -84(%rsp) movss %xmm4, -88(%rsp) movsd %xmm5, -96(%rsp) movsd %xmm6, -104(%rsp) }}} Later on when the function makes a recursive call to itself the code generated is {{{ movq -8(%rsp), %rbp movq -16(%rsp), %r12 movq -24(%rsp), %rbx movq -32(%rsp), %r14 movq -40(%rsp), %rsi movq -72(%rsp), %r15 popq %rax jmp Fib_zdwloop_info # TAILCALL }}} Given that the values are being loaded from the stack to the registers in the second excerpt, it is redundant to re-store the same values into the stack at the entry of the function. It seems to me that this is happening because LLVM uses a general function call instruction to translate a function calling itself. I was wondering if it is possible to recognize this special case in the LLVM backed or earlier so that instead of a function call we can translate this as the LLVM level as a jump to some point after the function entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:39:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:39:09 -0000 Subject: [GHC] #9387: LLVM backend: redundant code for functions calling themselves In-Reply-To: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> References: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> Message-ID: <058.52a448563516349a95868a2c3d806b47@haskell.org> #9387: LLVM backend: redundant code for functions calling themselves -------------------------------------+------------------------------------- Reporter: jmoy | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (LLVM) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jmoy: Old description: > It seems that the LLVM backed does not recognize when a function calls > itself. As a result it generates redundant load and store instructions. > > I am compiling the following simple recursive Fibonacci function > > {{{ > fib::Int->Int > fib n > = loop n 0 1 > where > loop !n !a !b > = if n==1 then > a > else > loop (n-1) b (a+b) > }}} > > I am attaching the files produced by > > {{{ > ghc -c -O3 -fllvm -ddump-stg -ddump-cmm -ddump-llvm -ddump-to-file Fib.hs > }}} > > I rename the generated LLVM file with a `.ll` extension and run `llc -O3` > on it to generate the attached `.s` file (LLVM version 3.4.2). > > The actual work gets done in `Fib_zdwloop_info`. It begins as: > > {{{ > Fib_zdwloop_info: # @Fib_zdwloop_info > # BB#0: # %css > pushq %rax > movq %r13, (%rsp) > movq %rbp, -8(%rsp) > movq %r12, -16(%rsp) > movq %rbx, -24(%rsp) > movq %r14, -32(%rsp) > movq %rsi, -40(%rsp) > movq %rdi, -48(%rsp) > movq %r8, -56(%rsp) > movq %r9, -64(%rsp) > movq %r15, -72(%rsp) > movss %xmm1, -76(%rsp) > movss %xmm2, -80(%rsp) > movss %xmm3, -84(%rsp) > movss %xmm4, -88(%rsp) > movsd %xmm5, -96(%rsp) > movsd %xmm6, -104(%rsp) > }}} > > Later on when the function makes a recursive call to itself the code > generated is > > {{{ > movq -8(%rsp), %rbp > movq -16(%rsp), %r12 > movq -24(%rsp), %rbx > movq -32(%rsp), %r14 > movq -40(%rsp), %rsi > movq -72(%rsp), %r15 > popq %rax > jmp Fib_zdwloop_info # TAILCALL > }}} > > Given that the values are being loaded from the stack to the registers in > the second excerpt, it is redundant to re-store the same values into the > stack at the entry of the function. > > It seems to me that this is happening because LLVM uses a general > function call instruction to translate a function calling itself. I was > wondering if it is possible to recognize this special case in the LLVM > backed or earlier so that instead of a function call we can translate > this as the LLVM level as a jump to some point after the function entry. New description: It seems that the LLVM backed does not recognize when a function calls itself. As a result it generates redundant load and store instructions. I am compiling the following simple recursive Fibonacci function {{{ fib::Int->Int fib n = loop n 0 1 where loop !n !a !b = if n==1 then a else loop (n-1) b (a+b) }}} I am attaching the files produced by {{{ ghc -c -O3 -fllvm -ddump-stg -ddump-cmm -ddump-llvm -ddump-to-file Fib.hs }}} I rename the generated LLVM file with a `.ll` extension and run `llc -O3` on it to generate the attached `.s` file (LLVM version 3.4.2). The actual work gets done in `Fib_zdwloop_info`. It begins as: {{{ Fib_zdwloop_info: # @Fib_zdwloop_info # BB#0: # %css pushq %rax movq %r13, (%rsp) movq %rbp, -8(%rsp) movq %r12, -16(%rsp) movq %rbx, -24(%rsp) movq %r14, -32(%rsp) movq %rsi, -40(%rsp) movq %rdi, -48(%rsp) movq %r8, -56(%rsp) movq %r9, -64(%rsp) movq %r15, -72(%rsp) movss %xmm1, -76(%rsp) movss %xmm2, -80(%rsp) movss %xmm3, -84(%rsp) movss %xmm4, -88(%rsp) movsd %xmm5, -96(%rsp) movsd %xmm6, -104(%rsp) }}} Later on when the function makes a recursive call to itself the code generated is {{{ movq -8(%rsp), %rbp movq -16(%rsp), %r12 movq -24(%rsp), %rbx movq -32(%rsp), %r14 movq -40(%rsp), %rsi movq -72(%rsp), %r15 popq %rax jmp Fib_zdwloop_info # TAILCALL }}} Given that the values are being loaded from the stack to the registers in the second excerpt, it is redundant to re-store the same values into the stack at the entry of the function. It seems to me that this is happening because LLVM uses a general function call instruction to translate a function calling itself. I was wondering if it is possible to recognize this special case in the LLVM backed or earlier so that instead of a function call we can translate this at the LLVM level as a jump to some point after the function entry. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 17:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 17:43:33 -0000 Subject: [GHC] #9387: LLVM backend: redundant code for functions calling themselves In-Reply-To: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> References: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> Message-ID: <058.94bf09809077546401f0b0a93f089f97@haskell.org> #9387: LLVM backend: redundant code for functions calling themselves -------------------------------------+------------------------------------- Reporter: jmoy | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (LLVM) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jmoy): * cc: jyotirmoy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 19:51:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 19:51:19 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.7af0cdbadbf1f7bef4b6565cfc839241@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Compilers built with `-O` match the current `mod73.stderr` order and compilers built with `-O0` match the order proposed in this ticket. Given that the order depends on the ids of `FastString`s, I guess this isn't necessarily cause for alarm, though I don't have a specific explanation for it. ezyang added support for custom output checkers in f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e, so for now we can configure the test to allow either output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 19:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 19:54:12 -0000 Subject: [GHC] #9387: LLVM backend: redundant code for functions calling themselves In-Reply-To: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> References: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> Message-ID: <058.4c538bdb29e532dea1dd7bd8acd04c4f@haskell.org> #9387: LLVM backend: redundant code for functions calling themselves -------------------------------------+------------------------------------- Reporter: jmoy | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (LLVM) | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): on the mailing list, its mentioned that if opt is invoked before llc, this performance issue goes away. http://www.haskell.org/pipermail/haskell-cafe/2014-July/115325.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 20:22:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 20:22:24 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.f56c2cfb6c5341bdb8e8ccbcfe0ba99f@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. Is this with `ghc --make`? Then yes, that sounds plausible. * When compiling a module M with -O, and then reading an interface file to support that compilation, GHC makes the unfolding of Ids in that interface file. * With `ghc --make` when GHC goes on to compile a new module L, it doesn't re-read interface files it has already read (that is part of why `--make` is faster). So the already-read Ids still have those unfoldings in them. * As a result, if L is compiled with -O0, it will still see the unfoldings. I can see that is perplexing. If it's important, the solution would be to disable inlining for imported functions when -O0 is on. (Actually, more precisely, it's controlled by `-fignore-interface-pragmas`.) I don't think it would be terribly hard to do that, although it would be an extra test on every inlining for an imported function. I still wish someone could explain why it's so crucial for this module to be compiled with -O0. That must be a bug, either in the RULES for some package, or in GHC. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 21:06:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 21:06:28 -0000 Subject: [GHC] #1620: ModBreaks.modBreaks_array not initialised In-Reply-To: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> References: <044.53d725b3007e15a81cf7af24407f5869@haskell.org> Message-ID: <059.d77074a7b6973c5e05d7179f2cd326ab@haskell.org> #1620: ModBreaks.modBreaks_array not initialised -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * version: 7.8.3 => 7.8.2 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 30 22:52:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jul 2014 22:52:36 -0000 Subject: [GHC] #9387: LLVM backend: redundant code for functions calling themselves In-Reply-To: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> References: <043.daecc0595c8a0e21fcbe72663bba812a@haskell.org> Message-ID: <058.54ed2496cc6611e5e78fa1c92c3dc9ed@haskell.org> #9387: LLVM backend: redundant code for functions calling themselves -------------------------------------+------------------------------------- Reporter: jmoy | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: (LLVM) | Architecture: x86_64 (amd64) Resolution: invalid | Difficulty: Unknown Operating System: Linux | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: [http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/051355.html This mailing list thread] has more information on `opt` vs `llc`, with a similar example. Use `ghc -v` to see the steps GHC goes through to compile your file. It runs `opt` before `llc`, and you can see from inspecting `Fib.o` that the stack spilling is not present. (You can also inspect the actual intermediate files with `ghc -v -keep-tmp-files`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 02:11:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 02:11:05 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.d5cc33350842a0cfed9a36f22245023b@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"b06e83dee5f7ec32efb4c424b0450a6c55359239/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b06e83dee5f7ec32efb4c424b0450a6c55359239" Make mod73 test insensitive to minor variations (#9325) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 02:11:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 02:11:53 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.b0091de46c2974b959343ce04093004f@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I found that I could use a custom stderr normaliser instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 07:11:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 07:11:56 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.5c4820e8ba5c77b36ccc7466974c0386@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Just for completeness, here is the proposed specification again, with the fixes above, except for the remarks about incoherence in comments 22-24: {{{ The willingness to be overlapped or incoherent is a property of the instance declaration itself, controlled as follows: * An instance is "incoherent" if it has an INCOHERENT pragama, or if it appears in a module compiled with -XIncoherentInstances. * An instance is "overlappable" if it has an OVERLAPPABLE or OVERLAPS pragama, or if it appears in a module compiled with -XOverlappingInstances, or if the instance is incoherent. * An instance is "overlapping" if it has an OVERLAPPING or OVERLAPS pragama, or if it appears in a module compiled with -XOverlappingInstances, or if the instance is incoherent. compiled with -XOverlappingInstances. Now suppose that, in some client module, we are searching for an instance of the target constraint (C ty1 .. tyn). The search works like this. * Find all instances I that match the target constraint; that is, the target constraint is a substitution instance of I. These instance declarations are the candidates. * Find all non-candidate instances that unify with the target constraint. Such non-candidates instances might match when the target constraint is further instantiated. If all of them are incoherent, proceed; if not, the search fails. * Eliminate any candidate IX for which both of the following hold: * There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable or IY is overlapping. * If only one candidate remains, pick it. Otherwise if all remaining candidates are incoherent, pick an arbitrary candidate. Otherwise fail. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 07:55:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 07:55:43 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.a45ac7eeeb5d2dca48c13b2c26dbd085@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp -------------------------------------+------------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"da70f9ef49a545707dc32db9662441b9c8845fba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da70f9ef49a545707dc32db9662441b9c8845fba" Allow multiple entry points when allocating recursive groups (#9303) Summary: In this example we ended up with some code that was only reachable via an info table, because a branch had been optimised away by the native code generator. The register allocator then got confused because it was only considering the first block of the proc to be an entry point, when actually any of the info tables are entry points. Test Plan: validate Reviewers: simonpj, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D88 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 08:01:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 08:01:38 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.608d5e67e47a219f67592566d6c2a2c4@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Quoting from the spec: * Eliminate any candidate IX for which both of the following hold: * There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable or IY is overlapping. Mathematically, this makes a lot of sense. But put on the hat of library writers, and users, and users that don't rtfm. Looking out from under this hat, the one may always wonder whether one should make one's generic instances OVERLAPPABLE or not. If I create a library with type class Bla and {{{ instance Bla a => Bla [a] }}} I could be a nice library writer and spare my users from declaring their Bla String instances as OVERLAPPING, so I'd write {{{ instance {-# OVERLAPPABLE #-} Bla a => Bla [a] }}} Or maybe that would be malicious? I think the current proposal is too sophisticated. There are no convincing examples given in the discussion so far that demonstrate where this sophistication pays off in practice. Keep in mind that 99% of the Haskell users will never study the instance resolution algorithm or its specification, but just flip on/off pragmas until their code goes through. [At least that was my approach: whenever GHC asks for one more LANGUAGE pragma, just throw it in.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 08:13:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 08:13:19 -0000 Subject: [GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp In-Reply-To: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> References: <045.e0bedc65ff006276ebfbf64f127a76b6@haskell.org> Message-ID: <060.982dbad3e674a5edd2466becfb5be52f@haskell.org> #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp -------------------------------------+------------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 08:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 08:58:13 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.164ef4e2be90e4d0f92bcb3794dc1e0e@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 09:40:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 09:40:52 -0000 Subject: [GHC] #9379: Blocked STM transaction is not interruptible In-Reply-To: <048.943534b67221dbed25ba3c1c69579c2c@haskell.org> References: <048.943534b67221dbed25ba3c1c69579c2c@haskell.org> Message-ID: <063.ea85f92478fcb42b642463b384aa933c@haskell.org> #9379: Blocked STM transaction is not interruptible -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D104| -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => https://phabricator.haskell.org/D104 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 10:50:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 10:50:43 -0000 Subject: [GHC] #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8); ` In-Reply-To: <042.61b5d8d63186bd136b03c5418b6145b5@haskell.org> References: <042.61b5d8d63186bd136b03c5418b6145b5@haskell.org> Message-ID: <057.9c812bad1244ac766e75f127604091b2@haskell.org> #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D105| -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => https://phabricator.haskell.org/D105 * milestone: 7.10.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 11:06:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 11:06:08 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.5dab371b2e0ddc3082d3c950c2f42e3f@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The Cmm code looks ok to me. Maybe someone could trace through with gdb to find out where the error is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 12:20:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 12:20:16 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.f319cda074c75c515a4452303db87ba9@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think I know what is going on. Consider `test0`: {{{ test0 = let s = cast A (SomeS (S 0)) in case viewV0 s of V0A{} -> putStrLn "test0 - A" V0B{} -> putStrLn "test0 - B" }}} Remember that `cast :: forall a. M -> SomeS -> S a`, so that `s` is a polymorphic value: `s :: forall (x::M). S x`. Now at the occurrence of `s` on the next line, GHC has to choose what type to instantiate `s` at; that is, what to instantiate `x` with. The calling context is no help, so GHC simply has to guess any old type, of kind `M`. It could randomly choose `A` or `B`, but that seems arbitrary. So it chooses `Any M`, where `Any :: forall k. k` is a built-in type family that has no equations. It's as if it was declared with {{{ type family Any :: k }}} So now `(viewV0 s)` has type `V0 (Any M)`. The trouble is that in GHC 7.8, `Any` was a ''data type'' not a type family. That was wrong for many reasons, but this ticket exposes a new one. In a `case` expression, GHC discards any patterns that can't possibly match the scrutinee. The two patterns in the case expression in `test0` have types `V0 A` and `V0 B`. Since `A` and `Any M` are different (if `Any` is a data type) GHC discarded that alternative, and the same for the other one. In HEAD, `Any` is a type family (see #9097), so GHC (rightly) does not know that `Any M` and `A` are distinct. So the alternative is not discarded. I have not followed through all the other cases, but I bet that it's all attributable to that one fix. I will add this as regression test, despite the unsavoury use of `unsafeCoerce`. I don't propose to fix 7.8.4. I think there were various reasons that `Any` was not made a type family earlier. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 12:31:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 12:31:11 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.e1a992b4a571929491d0d513ed991e08@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: gadt/T9380 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => closed * testcase: => gadt/T9380 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 13:51:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 13:51:35 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.b215dec0472a54f8536ea17a7f968d1d@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: gadt/T9380 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by maxtaldykin): Here is a bit more concise test case (derived from the original one): {{{ {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} import Unsafe.Coerce data X = A | B data Y (x :: X) where YA :: Y A YB :: Y B Yany :: String -> Y x view :: Y a -> Y b view = unsafeCoerce main :: IO () main = case view YA of YA -> putStrLn "YA" YB -> putStrLn "YB" Yany x -> putStrLn x }}} This will cause segmentation fault on 7.8.3 due to matching `YA` with `Yany` and trying to access `String` that does not exist. In HEAD it will print `YA`. But is it really intended behavior? My reasoning is that this is an example of unsafe using of `unsafeCoerce`. Due to `view`'s parametricity GHC can infer that all valid implementations (except _|_) are of the form {{{ view :: Y a -> Y b view = const (Yany "some string here") }}} And it is safe to optimize `main` by dropping `YA` and `YB` cases. But if we allow such usage of `unsafeCoerce` then it is no longer possible to optimize cases even if `view` absolutely safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 13:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 13:56:29 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.411cda323fc422e5b7343c0a93ce0562@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: gadt/T9380 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I think HEAD is fine here. The call `view YA` gets type `Y (Any X)`, and that's a very reasonable type for it. I don't see a difficulty here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:30:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:30:17 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" Message-ID: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The "state hack" has caused any number of bug reports (just search for that string), the most recent of which is #9349. Here's an idea to make it less pervasive: (roughly) use the state hack only for top-level functions definitions. The idea is that for nested lambdas the context should give the one-shot- ness, now that we are equipped with cardinality analysis. For example, consider the call {{{ replicatM_ 1000 (\(s :: RealWorld#) -> blah) }}} The lambda is 1000-shot, not one-shot, notwithstanding the type of the binder. Moreover `replicateM_`'s strictness/cardinality signature will say just that, and GHC already knows how to propagate that information onto the `\s`. But for top level functions like {{{ pr :: String -> IO () pr x = putStrLn (reverse x) }}} we get Core {{{ pr = \x. let y = reverse x in \ (s :: State# RealWorld). putStrLn y s }}} and, since we can't see all the callers of `pr`, we don't know if work is lost by pushing the `reverse` call inside, to get {{{ pr = \x. (s :: State# RealWorld). putStrLn (reverse x) s }}} which is much more efficient. Indeed, this might not be so good if the calls looked like {{{ ... replicateM_ 1000 (pr "foo")... }}} because then "foo" will be reversed 1000 times. But arguably that's what the programmer expects anyway, looking at the code; and the efficiency hit from not eta-expanding all functions like `pr` (which are very very common) is significant. The point is the that the only ones that need hacking are the top-level guys, and maybe even the top-level ''exported'' guys. I have not fully thought this through, let alone tried it out, but I wanted to capture the thought. It would need some careful performance testing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:38:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:38:53 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.327f003aeac19aa5275d30514a3c5527@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): That makes sense to me -- another fairly easy TH improvement waiting for a willing volunteer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:49:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:49:50 -0000 Subject: [GHC] #9380: ghc generates seemingly incorrect code In-Reply-To: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> References: <045.6844453ffd97f9fdf79859abbeaa8f92@haskell.org> Message-ID: <060.1373d81ac322e06a51395ddcf5ab3c39@haskell.org> #9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: gadt/T9380 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"dc7d3c2d437b310d26b05033d1b34601e1914d00/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dc7d3c2d437b310d26b05033d1b34601e1914d00" Test Trac #9380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:49:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:49:50 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.df6ba77a43290f18e4932387c15a9401@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bfaa17998ed0cb8b22132d8e824b274ac5f038cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bfaa17998ed0cb8b22132d8e824b274ac5f038cc" Add comments about the {-# INCOHERENT #-} for Typeable (f a) C.f. Trac #9242 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:49:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:49:50 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.2b7514b8d2a793d8ff9a77fb18c1a350@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1ae5fa451f4f554e0d652d55f9312a585188ce13/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1ae5fa451f4f554e0d652d55f9312a585188ce13" Complete work on new OVERLAPPABLE/OVERLAPPING pragmas (Trac #9242) * Deprecate -XOverlappingInstances * Update test suite. Several tests even had entirely unnecessary uses of -XOverlappingInstances * Update user manual with a careful description of the instance resolution story * Fix an outright bug in the handling of duplidate instances in GHCi, which are meant to silently overwrite the earlier duplicate. The logic was right for family instances but was both more complicated, and plain wrong, for class instances. (If you are interested, the bug was that we were eliminating the duplicate from the InstEnv, but not from the [ClsInst] held in tcg_insts.) Test is ghci044a. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 14:58:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 14:58:05 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.1ab4acad511434c7b4118493669f2015@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): So what remains now is to decide about the behaviour of "incoherent". Here is a possible re-draft: {{{ Suppose that, in some client module, we are searching for an instance of the target constraint (C ty1 .. tyn). The search works like this. * Find all instances I that match the target constraint; that is, the target constraint is a substitution instance of I. These instance declarations are the candidates. * Eliminate any candidate IX for which both of the following hold: * There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable or IY is overlapping. * If only one candidate remains, pick it. Otherwise if all remaining candidates are incoherent, pick an arbitrary candidate. Otherwise fail. * If the selected candidate (from the previous step) is not incoherent, then find all non-candidate instances that unify with the target constraint. Such non-candidates instances might match when the target constraint is further instantiated. If all of them are incoherent, proceed; if not, the search fails. * Return the selected candidate. }}} The difference is that we are slightly more permissive in the case of incoherent instances: if the selected candidate is incoherent, then we ignore all unifying ones. That would allow us to write {{{ instance {-# INCOHERENT #-} Typeable (n::Nat) where ... instance (Typeable f, Typeable a) => Typeable (f a) where ... }}} as was proposed in the original Description of this ticket, rather than making the `(f a)` instance incoherent. I think this would affect practically no one, and would accept a few more programs. So I don't think it's very controversial. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 18:35:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 18:35:54 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.a05b29ce334da10ee2d3f244419b680a@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Not sure whether it was this patch that caused the issue, but from today's head I get: {{{ =====> ghci044(ghci) 994 of 4062 [0, 0, 0] cd ./ghci/scripts && HC='/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc- stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ghci044.run.stdout 2>ghci044.run.stderr Actual stdout output differs from expected: --- /dev/null 2014-07-31 19:25:24.000000000 +0100 +++ ./ghci/scripts/ghci044.run.stdout 2014-07-31 19:25:24.000000000 +0100 @@ -0,0 +1,3 @@ +"First" +"First" +"First" *** unexpected failure for ghci044(ghci) =====> T4801(normal) 2001 of 4062 [0, 1, 0] cd ./perf/compiler && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs +RTS -V0 -tT4801.comp.stats --machine- readable -RTS -static >T4801.comp.stderr 2>&1 max_bytes_used value is too high: Expected T4801(normal) max_bytes_used: 25145320 +/-5% Lower bound T4801(normal) max_bytes_used: 23888054 Upper bound T4801(normal) max_bytes_used: 26402586 Actual T4801(normal) max_bytes_used: 26679688 Deviation T4801(normal) max_bytes_used: 6.1 % peak_megabytes_allocated value is too high: Expected T4801(normal) peak_megabytes_allocated: 70 +/-1% Lower bound T4801(normal) peak_megabytes_allocated: 69 Upper bound T4801(normal) peak_megabytes_allocated: 71 Actual T4801(normal) peak_megabytes_allocated: 73 Deviation T4801(normal) peak_megabytes_allocated: 4.3 % bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T4801(normal) bytes allocated: 464872776 +/-5% Lower bound T4801(normal) bytes allocated: 441629137 Upper bound T4801(normal) bytes allocated: 488116415 Actual T4801(normal) bytes allocated: 433471304 Deviation T4801(normal) bytes allocated: -6.8 % *** unexpected failure for T4801(normal) =====> haddock.base(normal) 2014 of 4062 [0, 2, 0] max_bytes_used value is too high: Expected haddock.base(normal) max_bytes_used: 115113864 +/-10% Lower bound haddock.base(normal) max_bytes_used: 103602477 Upper bound haddock.base(normal) max_bytes_used: 126625251 Actual haddock.base(normal) max_bytes_used: 127616088 Deviation haddock.base(normal) max_bytes_used: 10.9 % *** unexpected failure for haddock.base(normal) =====> T9203(normal) 2050 of 4062 [0, 3, 0] cd ./perf/should_run && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -o T9203 T9203.hs -O2 >T9203.comp.stderr 2>&1 cd ./perf/should_run && ./T9203 +RTS -V0 -tT9203.stats --machine-readable -RTS T9203.run.stdout 2>T9203.run.stderr bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9203(normal) bytes allocated: 95747304 +/-5% Lower bound T9203(normal) bytes allocated: 90959938 Upper bound T9203(normal) bytes allocated: 100534670 Actual T9203(normal) bytes allocated: 42946176 Deviation T9203(normal) bytes allocated: -55.1 % *** unexpected failure for T9203(normal) =====> T5435_dyn_asm(normal) 2491 of 4062 [0, 4, 0] cd ./rts && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm.run.stdout 2>T5435_dyn_asm.run.stderr T5435_dyn_asm failed with ['modInitFunc1', 'modInitFunc2', 'success'], see all.T for details *** unexpected failure for T5435_dyn_asm(normal) Unexpected results from: TEST="T9203 T5435_dyn_asm ghci044 haddock.base T4801" OVERALL SUMMARY for test run started at Thu Jul 31 19:25:23 2014 BST 0:00:05 spent to go through 4062 total tests, which gave rise to 19508 test cases, of which 19503 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 5 unexpected failures Unexpected failures: ghci/scripts ghci044 [bad stdout] (ghci) perf/compiler T4801 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) rts T5435_dyn_asm [bad stdout] (normal) }}} This is with BuildFlavour = perf on a Mac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 18:43:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 18:43:03 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.3d1ba4db6dfc7870db291db636ffb4bc@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by joe9mail): I would love to have this feature. Thanks a lot for adding it in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 20:34:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 20:34:22 -0000 Subject: [GHC] #9325: mod73 output file needs to be reordered In-Reply-To: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> References: <042.5cfea22b807f5de9e64a3ea11ae4c297@haskell.org> Message-ID: <057.ece53a1af9d099e9f80b07ac08d21905@haskell.org> #9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: mod73 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: mod73 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): ghci044 is my fault, will fix. I don't know about the others. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 31 23:09:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jul 2014 23:09:26 -0000 Subject: [GHC] #9389: Full Test Suite Failures Message-ID: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> #9389: Full Test Suite Failures ------------------------------------+---------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+---------------------------------- This is just to record progress on running the full test suite on OS X for the current HEAD using a BuildFlavour = perf build. I'll check through these (some of which are configuration issues because of the non-standard build or some required libraries are not being pulled in). {{{ OVERALL SUMMARY for test run started at Thu Jul 31 23:03:39 2014 BST 0:32:31 spent to go through 4036 total tests, which gave rise to 19262 test cases, of which 4218 were skipped 358 had missing libraries 14485 expected passes 135 expected failures 0 caused framework failures 0 unexpected passes 66 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals004 [bad exit code] (threaded2) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) ffi/should_run ffi002 [bad exit code] (threaded2) indexed-types/should_compile T7837 [stderr mismatch] (profasm) perf/compiler T4801 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) profiling/should_run callstack001 [bad stdout] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts T5435_dyn_asm [bad stdout] (normal) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts overflow1 [bad exit code] (hpc,optasm,profasm,threaded2,dyn,profthreaded,optllvm) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) simplCore/should_compile T7702 [exit code non-0] (profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler