From ghc-devs at haskell.org Fri Aug 1 03:23:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 03:23:37 -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.c648f1ebb4e5c15ddf8e37942a91743f@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 rwbarton): I would guess it's to avoid the very code size explosion (inlining 4000 copies of Text's `fromString`) that Carter encountered that originated this ticket. But that doesn't explain the `-fno-case-merge -fno-strictness -fno-cse` part. Carter has asked about this on the xmlhtml bug tracker. The same scenario could apply in reverse, right? In the actual xmlhtml package, `Text.XmlHtml.HTML.Meta` is the first module built and it is built with `-O0` so any interface files that are read while compiling that module will not have unfoldings attached. Then those modules will not have unfoldings during the compilation of any subsequent module either, even though those are built with `-O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 04:57:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 04:57:44 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples Message-ID: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.IO (IO (..)) import GHC.Prim writeB :: MutableArray# RealWorld Char -> IO () writeB arr# = IO $ \s0# -> (# writeArray# arr# 0# 'B' s0#, () #) inlineWriteB :: MutableArray# RealWorld Char -> () inlineWriteB arr# = case f realWorld# of (# _, x #) -> x where IO f = writeB arr# test :: IO Char test = IO $ \s0# -> case newArray# 1# 'A' s0# of (# s1#, arr# #) -> case seq# (inlineWriteB arr#) s1# of (# s2#, () #) -> readArray# arr# 0# s2# main :: IO () main = test >>= print }}} I would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring. This affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11), but this should probably be fixed in GHC as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 05:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 05:00:21 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.1753e9297af696b4cdd6a8576a92d8b7@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Note that the following similar code does not reproduce this issue: {{{#!hs import GHC.IO (IO (..)) import GHC.Prim writeB :: MutableArray# RealWorld Char -> () writeB arr# = case writeArray# arr# 0# 'B' realWorld# of _ -> () test :: IO Char test = IO $ \s0# -> case newArray# 1# 'A' s0# of (# s1#, arr# #) -> case seq# (writeB arr#) s1# of (# s2#, () #) -> readArray# arr# 0# s2# main :: IO () main = test >>= print }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 05:54:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 05:54:45 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.683acc7bc3162c1f930540d5891ce57a@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): {{{ {-# LANGUAGE BangPatterns, UnboxedTuples,MagicHash #-} import Data.ByteString.Internal (inlinePerformIO) import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM import System.IO.Unsafe main :: IO () main = do vm <- VM.new 1 VM.write vm 0 'A' !b<- return $! 'B' let !x = unsafePerformIO $! VM.write vm 0 b x `seq` (V.freeze vm >>= print) }}} will output fromList "B" at O0 and and fromList "A" at O1 and O2, so Its not related to using InlinePerformIO (which made me a bit more skeptical, but then i then saw that I can hit this problem without accurseevilperformIO) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 06:07:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 06:07:07 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.9bff200f3c13d7db07f5a5bdf0ab2fdf@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): its important to also note from the docs in GHC.Prim data State# s Source State# is the primitive, unlifted type of states. It has one type parameter, thus State# RealWorld, or State# s, where s is a type variable. The only purpose of the type parameter is to keep different state threads separate. It is represented by nothing at all. data RealWorld Source RealWorld is deeply magical. It is primitive, but it is not unlifted (hence ptrArg). We never manipulate values of type RealWorld; it's only used in the type system, to parameterise State#. i'm not sure if your expectations on the evaluation are correct from this perspective. I could /likely am incorrect though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 06:51:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 06:51:28 -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.a606101d7e1a7c9fe97f0f5277f04de2@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): Replying to [comment:11 rwbarton]: > I would guess it's to avoid the very code size explosion (inlining 4000 copies of Text's `fromString`) I would guess so too. But WHY is 4000 copies of `fromString` getting inlined. I doubt GHC is doing that unaided. I bet it's an INLINE pragma or RULE in Text. And if so, it's a landmine waiting to kill new victims. > The same scenario could apply in reverse, right? In the actual xmlhtml package, `Text.XmlHtml.HTML.Meta` is the first module built and it is built with `-O0` so any interface files that are read while compiling that module will not have unfoldings attached. Then those modules will not have unfoldings during the compilation of any subsequent module either, even though those are built with `-O`. No, that part at least is not so. The interface file built for `Text.XmlHtml.HTML.Meta` will not have unfoldings in it, but that only affects functions actually defined in `Text.XmlHtml.HTML.Meta`. Later modules, built with `-O` will certainly get interface files with unfoldings in them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 08:18:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 08:18:41 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.4255f5fe5d9388fff15437545dabb68f@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I can buy that interpretation, in which case it would seem that my pull request to primitive isn't a workaround, but the correct way to do things. It would be nice to get an authoritative answer on this, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 11:46:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 11:46:00 -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.18893bda374c45c6ca98b1393ca9e54e@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| -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"9d9a55469719908bbd5cd3277e0ac79c0588dc55/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9d9a55469719908bbd5cd3277e0ac79c0588dc55" interruptible() was not returning true for BlockedOnSTM (#9379) Summary: There's an knock-on fix in HeapStackCheck.c which is potentially scary, but I'm pretty confident is OK. See comment for details. Test Plan: I've run all the STM tests I can find, including libraries/stm/tests/stm049 with +RTS -N8 and some of the constants bumped to make it more of a stress test. Reviewers: hvr, rwbarton, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D104 GHC Trac Issues: #9379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 11:46:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 11:46:01 -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.92afe7d4777bcd2d9c2d53641a8b78d7@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| -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"2989ffdcb88ab24e8a4e8b3d0454497a0db2652c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2989ffdcb88ab24e8a4e8b3d0454497a0db2652c" A panic in CmmBuildInfoTables.bundle shouldn't be a panic (#9329) Summary: This code needs more comments, but I believe this is safe. By definition I can't have broken anything that was working by turning a panic into a non-panic anyway. Test Plan: validate Reviewers: hvr, simonpj, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D105 GHC Trac Issues: #9329 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 11:54:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 11:54:11 -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.4424be3189dc63e8b80b941eb45ed327@haskell.org> #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonmar Type: bug | Status: merge 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): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 11:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 11:54:49 -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.d1231c810ea484e072102d001ce7c6a1@haskell.org> #9379: Blocked STM transaction is not interruptible -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 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): * status: new => merge * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 12:23:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 12:23:34 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) Message-ID: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encountered Cmm like follows: {{{ cp7n: if ((Sp + -56) < SpLim) goto cp8c; else goto cp8d; ... cp8d: I64[Sp - 40] = block_cp7g_info; _smKL::P64 = P64[R1 + 7]; _smKO::P64 = P64[R1 + 15]; _smKP::P64 = P64[R1 + 23]; _smL0::P64 = P64[R1 + 31]; R1 = R2; P64[Sp - 32] = _smKL::P64; P64[Sp - 24] = _smKO::P64; P64[Sp - 16] = _smKP::P64; P64[Sp - 8] = _smL0::P64; Sp = Sp - 40; if (R1 & 7 != 0) goto up8R; else goto cp7h; up8R: call block_cp7g_info(R1) args: 0, res: 0, upd: 0; ... }}} which leads LLVM 3.2 to produce the following assembly: {{{ _smL1_info: ## @smL1_info ## BB#0: ## %cp7n pushq %rbp movq %rsp, %rbp movq %r14, %rax movq %rbp, %rcx leaq -56(%rcx), %rdx cmpq %r15, %rdx jae LBB160_1 ... LBB160_1: ## %cp8d leaq _cp7g_info(%rip), %rdx movq %rdx, -40(%rcx) vmovups 7(%rbx), %ymm0 vmovups %ymm0, -32(%rcx) addq $-40, %rcx testb $7, %al je LBB160_4 ## BB#2: ## %up8R movq %rcx, %rbp movq %rax, %rbx popq %rbp vzeroupper jmp _cp7g_info ## TAILCALL }}} So here LLVM has figured out that it can use `vmovups` in order to move 4 words at the same time. However, there is a puzzling side effect: All of sudden we have a `pushq %rbp` at the start of the function with a matching `popq %rbp` at the very end. This overwrites the stack pointer update (`movq %rcx, %rbp`) and - unsurprisingly - causes the program to crash rather quickly. My interpretation is that LLVM 3.2 erroneously thinks that AVX instructions are incompatible with frame pointer elimination. The reasoning is that this is exactly the kind of code LLVM generates if we disable this "optimisation" (`--disable-fp-elim`). Furthermore, disabling AVX instructions (`-mattr=-avx`) fixes the problem - LLVM falls back to the less efficient `movups`, with `pushq $rbp` vanishing as well. Finally, this bug seems to happen exactly with LLVM 3.2, with 3.3 upwards generating correct code. My proposed fix would be to add `-mattr=-avx` to the `llc` command line by default for LLVM 3.2. This issue might be related to #7694. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 12:56:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 12:56:38 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.4c2da3e7236675c086396d2a66b35590@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | 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: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this is very interesting. It turns out that * The desugarer was generating Core that did not satisfy the let/app invariant (in `CoreSyn`) * Core Lint was failing to check that the invariant was satisfied * The simplifier, quite reasonably, assumed that the invariant holds, and thereby discarded an expression that has side effects. Patch coming Great bug report, btw. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 13:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 13:57:45 -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.a46654a65e30d840aa13fd2b7f6da478@haskell.org> #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: #8848 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d4d4bef2a2a3b90e6c5cb3544e1c2057920ed572/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d4d4bef2a2a3b90e6c5cb3544e1c2057920ed572" Improve the desugaring of RULES, esp those from SPECIALISE pragmas In the code for Trac #8331 we were not getting a complaint, but we *were* getting a terrible (and virtually useless) RULE, looking like useAbstractMonad (complicated-dictionary-expresion) = $fuseAbstractMonad where we wanted useAbstractMonad d = $fuseAbstractMonad This commit improves the desugaring algorithm. More comments explain; see Note [Drop dictionary bindings on rule LHS] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 1 17:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Aug 2014 17:35:44 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages Message-ID: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Observe: {{{ Prelude> "a\nb" + () :2:10: Couldn't match expected type ?[Char]? with actual type ?()? In the second argument of ?(+)?, namely ?()? In the expression: "a\n\ \b" + () }}} Moreover, if ?\n? is at the end of the string, it simply gets eaten: {{{ Prelude> "a\n" + () :3:9: Couldn't match expected type ?[Char]? with actual type ?()? In the second argument of ?(+)?, namely ?()? In the expression: "a" + () }}} It happens in GHC as well as GHCi. Tested on 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 00:32:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 00:32:08 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.c9b15b866e5bdc72617cb19bc32db7d0@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 dterei): I'd like to propose we remove the `OVERLAPS` pragma. Why? == Long Version == https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances --a.k.aInstanceSpecificPragmas == Short Version (kind-of) == The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly different. Remember, in Safe Haskell we apply a policy of only allowing instances from a module M compiled with `-XSafe` to overlap other instances from module M. If it overlaps (and is the most specific overlap) instances from modules other than M then we don't allow this to succeed. This is done to ensure that untrusted code compiled with `-XSafe` can't alter the behavior of existing code, some of which may be part of the TCB and security critical. Brining the new finer grained pragmas into the story we get the following: * OVERLAPPABLE is the programmer communicating that they can be overlapped, an open instance if you will. We want to relax the above restriction and allow instances from `-XSafe` modules to overlap instances from their own module AND instances declared OVERLAPPABLE that reside in any module. * OVERLAPPING is the programming simply declaring they may overlap less specific instances. We want to keep the above restriction for these instances. That is, a instance I1 from a `-XSafe` module M won't be able to overlap as the most specific instance, a instance I2 from another module if I2 is marked as OVERLAPPING. This distinction enables new encodings in Safe Haskell by allowing security library authors to distinguish how untrusted code can overlap their instances. In some way giving them open vs closed instances. This distinction is subtle and important. Having a pragma OVERLAPS that implies both glosses over this and will encourage developers to use this without much thought. ## Safe Inference We can also safely infer a module that only has OVERLAPPABLE instances as safe, while ones that contain OVERLAPPING or OVERLAPS instances must be regarded as unsafe since there is a difference in semantics of these pragmas under Safe vs Unsafe. So we also have an advantage if developers are more specific about what they want, than just defaulting to OVERLAPS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 10:39:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 10:39:24 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.991af50bbc8858c33eeee0e1c665b0c1@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by jrp): Today's snapshot: {{{ OVERALL SUMMARY for test run started at Sat Aug 2 11:06:07 2014 BST 0:30:58 spent to go through 4042 total tests, which gave rise to 19285 test cases, of which 4222 were skipped 358 had missing libraries 14494 expected passes 135 expected failures 0 caused framework failures 0 unexpected passes 76 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 T367_letnoescape [bad exit code] (optllvm) concurrent/should_run T9379 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded,optllvm) concurrent/should_run T9379 [bad stdout or stderr] (ghci) 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) ghc-api ghcApi [exit code non-0] (optasm) indexed-types/should_compile T7837 [stderr mismatch] (profasm) perf/compiler T4801 [stat too good] (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 From ghc-devs at haskell.org Sat Aug 2 13:16:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 13:16:41 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR Message-ID: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | 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: -------------------------------------+------------------------------------- If PATH environment variable contains non directory component, execvpe fails by ENOTDIR. For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo". {{{ module Main where import System.Environment import System.Posix.Process main :: IO () main = do env <- getEnvironment executeFile "echo" True [] (Just env) return () }}} {{{ $ PATH=/tmp/foo:$PATH runghc a.hs a.hs: echo: executeFile: inappropriate type (Not a directory) }}} See for example, https://github.com/haskell/cabal/issues/1723 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 17:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 17:58:41 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command Message-ID: <047.01134e82983fb263026aa29a14aa8897@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance: {{{#!hs *Application> :info Route App class Eq (Route a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where data family Route a1 ... -- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class' instance Eq (Route App) -- Defined at Foundation.hs:48:1 instance Read (Route App) -- Defined at Foundation.hs:48:1 ................. }}} It just shows info about `Route`, then info about `App` separately. When I try this: {{{#!hs *Application> :info (Route App) :1:2: parse error on input `Route' }}} I am getting parse error. I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 19:57:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 19:57:56 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string Message-ID: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 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: -------------------------------------+------------------------------------- The current implementation of traceIO in Debug.Trace is as follows: {{{ traceIO :: String -> IO () traceIO msg = do withCString "%s\n" $ \cfmt -> withCString msg $ \cmsg -> debugBelch cfmt cmsg }}} This is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null. Probably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be: {{{ main = trace "\0foo" (return ()) }}} which should have non-empty output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 20:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 20:01:47 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.9a06f6b488414964612f66a2d28e0d78@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 jrp): The ghc build system itself still uses -XOverlappingInstances and so presumably needs to be updated too. {{{ "rm" -f libraries/haskeline/dist- install/build/.depend-v-dyn-p-dyn.haskell.tmp "inplace/bin/ghc-stage1" -M -static -O -H64m -package-name haskeline-0.7.1.2 -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist- install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DTERMINFO -optP-include -optPlibraries/haskeline/dist- install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package terminfo-0.4.0.0 -package transformers-0.4.1.0 -package unix-2.7.0.2 -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist- install/build -stubdir libraries/haskeline/dist-install/build -dep- makefile libraries/haskeline/dist- install/build/.depend-v-dyn-p-dyn.haskell.tmp -dep-suffix "" -dep-suffix "dyn_" -dep-suffix "p_" -dep-suffix "dyn_" -include-pkg-deps libraries/haskeline/./System/Console/Haskeline.hs libraries/haskeline/./System/Console/Haskeline/Completion.hs libraries/haskeline/./System/Console/Haskeline/MonadException.hs libraries/haskeline/./System/Console/Haskeline/History.hs libraries/haskeline/./System/Console/Haskeline/IO.hs libraries/haskeline/./System/Console/Haskeline/Backend.hs libraries/haskeline/./System/Console/Haskeline/Backend/WCWidth.hs libraries/haskeline/./System/Console/Haskeline/Command.hs libraries/haskeline/./System/Console/Haskeline/Command/Completion.hs libraries/haskeline/./System/Console/Haskeline/Command/History.hs libraries/haskeline/./System/Console/Haskeline/Command/KillRing.hs libraries/haskeline/dist- install/build/System/Console/Haskeline/Directory.hs libraries/haskeline/./System/Console/Haskeline/Emacs.hs libraries/haskeline/./System/Console/Haskeline/InputT.hs libraries/haskeline/./System/Console/Haskeline/Key.hs libraries/haskeline/./System/Console/Haskeline/LineState.hs libraries/haskeline/./System/Console/Haskeline/Monads.hs libraries/haskeline/./System/Console/Haskeline/Prefs.hs libraries/haskeline/./System/Console/Haskeline/RunCommand.hs libraries/haskeline/./System/Console/Haskeline/Term.hs libraries/haskeline/./System/Console/Haskeline/Command/Undo.hs libraries/haskeline/./System/Console/Haskeline/Vi.hs libraries/haskeline/./System/Console/Haskeline/Recover.hs libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix.hs libraries/haskeline/./System/Console/Haskeline/Backend/Posix/Encoder.hs libraries/haskeline/./System/Console/Haskeline/Backend/DumbTerm.hs libraries/haskeline/./System/Console/Haskeline/Backend/Terminfo.hs on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 21:02:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 21:02:30 -0000 Subject: [GHC] #8880: Configured gcc not used for some build steps In-Reply-To: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> References: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> Message-ID: <059.cccadf0f05d502f3721e96ab91a93cd3@haskell.org> #8880: Configured gcc not used for some build steps -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: duplicate | 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 jrp): I still get {{{ /usr/bin/gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer- arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict- aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -Wno-strict-prototypes -MM -x c rts/Adjustor.c -MF rts/dist/build/.depend-v-dyn-p-dyn-l-debug-thr- thr_debug-thr_l-thr_p-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn- thr_l_dyn.c_asm.bit In file included from rts/Adjustor.c:42: In file included from rts/RtsUtils.h:12: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/Adjustor.c:42: In file included from rts/RtsUtils.h:48: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop ^ In file included from rts/Adjustor.c:43: In file included from rts/Stable.h:18: In file included from rts/sm/GC.h:17: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/Adjustor.c:43: In file included from rts/Stable.h:18: In file included from rts/sm/GC.h:64: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop ^ In file included from rts/Adjustor.c:43: In file included from rts/Stable.h:20: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/Adjustor.c:43: In file included from rts/Stable.h:52: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop }}} This also occurs with homebrew clang 3.4.2 on the Mac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 21:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 21:34:59 -0000 Subject: [GHC] #9396: Code cleanup: warning: use of GNU old-style field designator extension Message-ID: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> #9396: Code cleanup: warning: use of GNU old-style field designator extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- The attached patch updates replaces GNU old-style designator syntax with C98 syntax for initializing structs. This gets rid of warnings such as {{{ rts/Profiling.c:90:1: warning: use of GNU old-style field designator extension [-Wgnu- designator] CC_DECLARE(CC_MAIN, "MAIN", "MAIN", "", CC_NOT_CAF, ); ^ includes/rts/prof/CCS.h:215:13: note: expanded from macro 'CC_DECLARE' = {{ ccID : 0, \ }}} ^ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 21:56:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 21:56:03 -0000 Subject: [GHC] #8880: Configured gcc not used for some build steps In-Reply-To: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> References: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> Message-ID: <059.ffb6350aecb98b5703a3096d04c91124@haskell.org> #8880: Configured gcc not used for some build steps -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: duplicate | 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 rwbarton): While it's somewhat off-topic, I'm confused because my "Debian clang version 3.4.2-4 (tags/RELEASE_34/dot2-final) (based on LLVM 3.4.2)" does know about `#pragma GCC visibility`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 22:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 22:09:14 -0000 Subject: [GHC] #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? Message-ID: <042.f0e7b987adecd19598b56f3435e8ff5d@haskell.org> #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | warning at compile-time Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Building ghc HEAD using 7.8.3 under OS X results in the following warnings: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get/Internal.hs -o libraries/binary/dist- install/build/Data/Binary/Get/Internal.o -dyno libraries/binary/dist- install/build/Data/Binary/Get/Internal.dyn_o libraries/binary/src/Data/Binary/Get/Internal.hs:314:1: Warning: Rule "<$> to <*>" may never fire because ?<$>? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?<$>? "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get.hs -o libraries/binary/dist- install/build/Data/Binary/Get.o -dyno libraries/binary/dist- install/build/Data/Binary/Get.dyn_o libraries/binary/src/Data/Binary/Get.hs:416:1: Warning: Rule "getWord8/readN" may never fire because ?getWord8? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord8? libraries/binary/src/Data/Binary/Get.hs:417:1: Warning: Rule "getWord16be/readN" may never fire because ?getWord16be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16be? libraries/binary/src/Data/Binary/Get.hs:418:1: Warning: Rule "getWord16le/readN" may never fire because ?getWord16le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16le? libraries/binary/src/Data/Binary/Get.hs:419:1: Warning: Rule "getWord32be/readN" may never fire because ?getWord32be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32be? libraries/binary/src/Data/Binary/Get.hs:420:1: Warning: Rule "getWord32le/readN" may never fire because ?getWord32le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32le? libraries/binary/src/Data/Binary/Get.hs:421:1: Warning: Rule "getWord64be/readN" may never fire because ?getWord64be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64be? libraries/binary/src/Data/Binary/Get.hs:422:1: Warning: Rule "getWord64le/readN" may never fire because ?getWord64le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64le? }}} Not sure what the probable fix is suggesting as the functions that are pointed are already marked as INLINE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 22:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 22:11:49 -0000 Subject: [GHC] #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? In-Reply-To: <042.f0e7b987adecd19598b56f3435e8ff5d@haskell.org> References: <042.f0e7b987adecd19598b56f3435e8ff5d@haskell.org> Message-ID: <057.6d4e092aa91e468982e4ddd0c3c0d3ed@haskell.org> #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jrp: Old description: > Building ghc HEAD using 7.8.3 under OS X results in the following > warnings: > {{{ > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src > -ilibraries/binary/dist-install/build -ilibraries/binary/dist- > install/build/autogen -Ilibraries/binary/dist-install/build > -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. > -optP-DGENERICS -optP-include -optPlibraries/binary/dist- > install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package > base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 > -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db > -rtsopts -odir libraries/binary/dist-install/build -hidir > libraries/binary/dist-install/build -stubdir libraries/binary/dist- > install/build -split-objs -dynamic-too -c > libraries/binary/src/Data/Binary/Get/Internal.hs -o libraries/binary > /dist-install/build/Data/Binary/Get/Internal.o -dyno libraries/binary > /dist-install/build/Data/Binary/Get/Internal.dyn_o > > libraries/binary/src/Data/Binary/Get/Internal.hs:314:1: Warning: > Rule "<$> to <*>" may never fire because ?<$>? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?<$>? > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src > -ilibraries/binary/dist-install/build -ilibraries/binary/dist- > install/build/autogen -Ilibraries/binary/dist-install/build > -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. > -optP-DGENERICS -optP-include -optPlibraries/binary/dist- > install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package > base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 > -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db > -rtsopts -odir libraries/binary/dist-install/build -hidir > libraries/binary/dist-install/build -stubdir libraries/binary/dist- > install/build -split-objs -dynamic-too -c > libraries/binary/src/Data/Binary/Get.hs -o libraries/binary/dist- > install/build/Data/Binary/Get.o -dyno libraries/binary/dist- > install/build/Data/Binary/Get.dyn_o > > libraries/binary/src/Data/Binary/Get.hs:416:1: Warning: > Rule "getWord8/readN" may never fire > because ?getWord8? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord8? > > libraries/binary/src/Data/Binary/Get.hs:417:1: Warning: > Rule "getWord16be/readN" may never fire > because ?getWord16be? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16be? > > libraries/binary/src/Data/Binary/Get.hs:418:1: Warning: > Rule "getWord16le/readN" may never fire > because ?getWord16le? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16le? > > libraries/binary/src/Data/Binary/Get.hs:419:1: Warning: > Rule "getWord32be/readN" may never fire > because ?getWord32be? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32be? > > libraries/binary/src/Data/Binary/Get.hs:420:1: Warning: > Rule "getWord32le/readN" may never fire > because ?getWord32le? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32le? > > libraries/binary/src/Data/Binary/Get.hs:421:1: Warning: > Rule "getWord64be/readN" may never fire > because ?getWord64be? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64be? > > libraries/binary/src/Data/Binary/Get.hs:422:1: Warning: > Rule "getWord64le/readN" may never fire > because ?getWord64le? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64le? > > }}} > > Not sure what the probable fix is suggesting as the functions that are > pointed are already marked as INLINE. New description: Building ghc HEAD using 7.8.3 under OS X results in the following warnings: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get/Internal.hs -o libraries/binary/dist- install/build/Data/Binary/Get/Internal.o -dyno libraries/binary/dist- install/build/Data/Binary/Get/Internal.dyn_o libraries/binary/src/Data/Binary/Get/Internal.hs:314:1: Warning: Rule "<$> to <*>" may never fire because ?<$>? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?<$>? "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name binary-0.7.1.0 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-install/build -ilibraries/binary/dist- install/build/autogen -Ilibraries/binary/dist-install/build -Ilibraries/binary/dist-install/build/autogen -Ilibraries/binary/. -optP-DGENERICS -optP-include -optPlibraries/binary/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -O2 -no-user-package-db -rtsopts -odir libraries/binary/dist-install/build -hidir libraries/binary/dist-install/build -stubdir libraries/binary/dist- install/build -split-objs -dynamic-too -c libraries/binary/src/Data/Binary/Get.hs -o libraries/binary/dist- install/build/Data/Binary/Get.o -dyno libraries/binary/dist- install/build/Data/Binary/Get.dyn_o libraries/binary/src/Data/Binary/Get.hs:416:1: Warning: Rule "getWord8/readN" may never fire because ?getWord8? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord8? libraries/binary/src/Data/Binary/Get.hs:417:1: Warning: Rule "getWord16be/readN" may never fire because ?getWord16be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16be? libraries/binary/src/Data/Binary/Get.hs:418:1: Warning: Rule "getWord16le/readN" may never fire because ?getWord16le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord16le? libraries/binary/src/Data/Binary/Get.hs:419:1: Warning: Rule "getWord32be/readN" may never fire because ?getWord32be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32be? libraries/binary/src/Data/Binary/Get.hs:420:1: Warning: Rule "getWord32le/readN" may never fire because ?getWord32le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord32le? libraries/binary/src/Data/Binary/Get.hs:421:1: Warning: Rule "getWord64be/readN" may never fire because ?getWord64be? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64be? libraries/binary/src/Data/Binary/Get.hs:422:1: Warning: Rule "getWord64le/readN" may never fire because ?getWord64le? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?getWord64le? }}} {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package-name template-haskell-2.10.0.0 -hide-all-packages -i -ilibraries /template-haskell/. -ilibraries/template-haskell/dist-install/build -ilibraries/template-haskell/dist-install/build/autogen -Ilibraries /template-haskell/dist-install/build -Ilibraries/template-haskell/dist- install/build/autogen -Ilibraries/template-haskell/. -optP-include -optPlibraries/template-haskell/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package pretty-1.1.1.1 -Wall -package-name template-haskell -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/template-haskell/dist-install/build -hidir libraries /template-haskell/dist-install/build -stubdir libraries/template-haskell /dist-install/build -split-objs -dynamic-too -c libraries/template- haskell/./Language/Haskell/TH/Syntax.hs -o libraries/template-haskell /dist-install/build/Language/Haskell/TH/Syntax.o -dyno libraries/template- haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o libraries/template-haskell/Language/Haskell/TH/Syntax.hs:505:11: Warning: Rule "TH:liftString" may never fire because ?lift? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?lift? }}} Not sure what the probable fix is suggesting as the functions that are pointed are already marked as INLINE. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 22:16:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 22:16:07 -0000 Subject: [GHC] #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? In-Reply-To: <042.f0e7b987adecd19598b56f3435e8ff5d@haskell.org> References: <042.f0e7b987adecd19598b56f3435e8ff5d@haskell.org> Message-ID: <057.e36fba99561f4fc3db4ad184b1e6e036@haskell.org> #9397: Probable fix: add an INLINE[n] or NOINLINE[n] pragma confused? -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid Comment: talk with the library maintainers, Not a ghc bug. GHC is conservatively linting the rewrite rules, not saying that the rules wont work ever. (i might be wrong how I'm reading, it but thats my take) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 2 22:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Aug 2014 22:32:33 -0000 Subject: [GHC] #8880: Configured gcc not used for some build steps In-Reply-To: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> References: <044.63c25d7af11908ebc05cbaf95265feed@haskell.org> Message-ID: <059.0f53efacafbcd259371fd1f9a4524994@haskell.org> #8880: Configured gcc not used for some build steps -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: duplicate | 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 jrp): I must say that I was surprised, as I thought that it should be supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 02:31:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 02:31:39 -0000 Subject: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised" In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> References: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> Message-ID: <059.3cda984c1bc5d9153ccbb02f0c8100ec@haskell.org> #2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: agdfrnd Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 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 agdfrnd): * owner: => agdfrnd * failure: => None/Unknown * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 04:32:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 04:32:48 -0000 Subject: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised" In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> References: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> Message-ID: <059.d3c6f0361868593fe91250747a2a68df@haskell.org> #2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 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 agdfrnd): * owner: agdfrnd => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 04:42:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 04:42:09 -0000 Subject: [GHC] #7662: Improve GC of mutable objects In-Reply-To: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> References: <045.1df59d879ca14d9200a5a4cc6e9474e1@haskell.org> Message-ID: <060.f6744f0162d405a9170c9bb6d85a8b0c@haskell.org> #7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.7 Component: Runtime | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 06:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 06:46:22 -0000 Subject: [GHC] #8206: Add support for Portable Native Client In-Reply-To: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> References: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> Message-ID: <059.7bc79c7c98e8f577d378bd984b8c9d15@haskell.org> #8206: Add support for Portable Native Client -------------------------------------+------------------------------------- Reporter: guest | Owner: Alex Sayers Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: NaCl PNaCl Resolution: | Portable Native Client pexe Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 07:39:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 07:39:01 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer Message-ID: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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.cycle is not a good producer. I'm not at all sure this solution is the best, but it allocates much less when mapped over and then folded. If we could make it a good consumer cheaply that would be nice too, but I imagine it's probably mostly applied to short lists, so that is probably not a priority. {{{#!hs {-# INLINE cycle #-} cycle :: [a] -> [a] cycle [] = error "Prelude.cycle: empty list" cycle xs = concat $ repeat xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 07:50:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 07:50:26 -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.e5e2157830785945531aace78a91c160@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by slomo): It didn't work btw, still resulting in the same dll-split error. So although ld.gold was configured and gcc was told to use gold for stage1/stage2, and the "settings" file for everything contained these settings, something was still using bfd in the end. However whenever I checked which processes are running, it was something that would use gold. Any ideas where to look? When changing /usr/bin/ld to ld.gold it should work, but that's not an option here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 07:53:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 07:53:47 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.1be2a4be0064a8965d83e287d5a82156@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: No, not ready yet. There are some more subtleties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 11:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 11:50:30 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string In-Reply-To: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> References: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> Message-ID: <060.ae224297e469435c24489e931b13fd55@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 15:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 15:11:36 -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.d889db5f824cddaafd2f75eb4de82379@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 rwbarton): Replying to [comment:12 simonpj]: > > The same scenario could apply in reverse, right? In the actual xmlhtml package, `Text.XmlHtml.HTML.Meta` is the first module built and it is built with `-O0` so any interface files that are read while compiling that module will not have unfoldings attached. Then those modules will not have unfoldings during the compilation of any subsequent module either, even though those are built with `-O`. > > No, that part at least is not so. The interface file built for `Text.XmlHtml.HTML.Meta` will not have unfoldings in it, but that only affects functions actually defined in `Text.XmlHtml.HTML.Meta`. Later modules, built with `-O` will certainly get interface files with unfoldings in them. Sorry, I should have been more clear. I mean that when GHC builds `Text.XmlHtml.HTML.Meta`, causing it to read the interface file for `Data.String`, optimization level `-O0` is in effect, so GHC will not read the unfolding for `Data.String.fromString`. Then, when GHC builds the next module `Text.XmlHtml.Common`, even though it is now at optimization level `-O1`, it reuses its in-memory interface file information for `Data.String` and therefore has no unfolding available for `fromString`, so it cannot inline it. If we force GHC to build `Text.XmlHtml.Common` before `Text.XmlHtml.HTML.Meta` by adding an import of the former to the latter, then GHC does inline `fromString` in `Text.XmlHtml.Common`. You can observe this either with `-ddump-inlinings -dverbose-core2core`, or by examining the symbol table of the resulting object file: there is no reference to an undefined symbol `base_DataziString_fromString_info`. This doesn't just apply to the module `Data.String`, of course; we might be missing many other opportunities to inline when we build the rest of the modules in this package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 13:15:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 13:15:28 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly Message-ID: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: cpp | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: enum01.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The printTest cpp macro does not seem to be being applied in the test suite test enum01.hs (libraries/base) {{{ > ghci -cpp enum01.hs 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 ( enum01.hs, interpreted ) enum01.hs:91:3: Not in scope: ?printTest? enum01.hs:92:3: Not in scope: ?printTest? : }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 14:39:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 14:39:38 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 Message-ID: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | 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: Compile- Blocked By: | time performance bug Related Tickets: #9370 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Spawned from #9370; see there for original discussion) Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl`. Then GHC takes ~1.5GB and over a minute to build this single module. Preliminary investigation indicates that Text's fromString and its constituent parts is being inlined repeatedly: {{{ 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 ] }}} resulting in a very large intermediate program: {{{ *** 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} ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 17:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 17:35:12 -0000 Subject: [GHC] #9402: Vestigial external core code in genprimops Message-ID: <047.41ab882fa71501e8a7cbcb7207176a86@haskell.org> #9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- It looks like `gen_ext_core_source` in `utils/genprimopcode/Main.hs` is no longer needed. I'm not quite confident enough here to make the change myself, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 18:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 18:34:01 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.a8f9e2857e75e9413dbe34291936ba72@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: closed => new * resolution: invalid => Old description: > Data.List.cycle is not a good producer. I'm not at all sure this solution > is the best, but it allocates much less when mapped over and then folded. > If we could make it a good consumer cheaply that would be nice too, but I > imagine it's probably mostly applied to short lists, so that is probably > not a priority. > > {{{#!hs > {-# INLINE cycle #-} > cycle :: [a] -> [a] > cycle [] = error "Prelude.cycle: empty list" > cycle xs = concat $ repeat xs > }}} New description: Data.List.cycle is not a good producer. I ''believe'' the following fixes it. The tests I've profiled so far suggest it does so. {{{#!hs {-# INLINE cycle #-} cycle :: [a] -> [a] cycle [] = error "Empty cycle." cycle xs = let cyc = augment cycle' cyc in cyc where cycle' c n = foldr c n xs }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:00:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:00:54 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.ba6752fb9017b6188ff5f285cca506c1@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): Remember that GHC doesn?t inline recursive things (such as `cyc`). Also, I don?t think your `cycle` is a good consumer: To inline it, you need to know that its argument is a `:`. But to make it a good consumer, the argument needs to be of the shape `build ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:18:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:18:46 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.8b3fe4dd155671cf7e14821404336e05@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:3 nomeata]: > Remember that GHC doesn?t inline recursive things (such as `cyc`). > > Also, I don?t think your `cycle` is a good consumer: To inline it, you need to know that its argument is a `:`. But to make it a good consumer, the argument needs to be of the shape `build ...`. I suppose I should (try to) find a way to rewrite it to another form if it doesn't get eaten by foldr. I'm not understanding your concern about the consumption side. `cyc` isn't inlined, but the enclosing `cycle` is. Shouldn't that be good enough to allow the `foldr` in `cycle'` to fuse with a `build` or `augment` in `xs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:19:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:19:39 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.7ffc60beef117048942b9608eaba7390@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): But note that you are pattern matching on `xs`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:41:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:41:32 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.5dae261dc5eda2a9d76540c439f36f07@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:5 nomeata]: > But note that you are pattern matching on `xs`! Ah, I see what you mean. That pattern match, however, is not essential. Suppose we leave it out. Then we get {{{#!hs cycle [] = let cyc = augment cycle' cyc in cyc where cycle' c n = foldr c n [] }}} `foldr/nil` gives {{{#!hs cycle [] = let cyc = augment (\c n -> []) cyc in cyc }}} Then applying `augment`: {{{#!hs cycle [] = let cyc = [] in cyc }}} So we've turned `_|_` into `[]`, whereas a similar omission from the current definition of `cycle` would turn an error into a much-less- desirable non-termination. This is not a disaster, and in fact it makes sense from a monoid perspective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:45:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:45:41 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.913b82f2a9eff4759b8f78dbd87c2103@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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 think you meant {{{#!hs cycle [] = let cyc = augment cycle' cyc in cyc where cycle' c n = foldr c n [] cycle [] = let cyc = augment (\c n -> n) cyc in cyc cycle [] = let cyc = cyc in cyc cycle [] = ? }}} so you turned a helpful error message into nontermination -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:57:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:57:34 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.d58a0832e55ba11800070a2ff370e348@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:7 nomeata]: > I think you meant > {{{#!hs > cycle [] = let cyc = augment cycle' cyc in cyc > where > cycle' c n = foldr c n [] > > cycle [] = let cyc = augment (\c n -> n) cyc in cyc I don't think so. Substituting `[]` for `xs`, `cycle' c n = foldr c n [] = []`, so `cycle' = \c n -> []`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 19:58:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 19:58:29 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.c283e1db5b1a1a4ce1edb964f8689cc0@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): `foldr c n [] = n`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 20:01:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 20:01:50 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.853d15173d5efded625c359f75e2b2fd@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:9 nomeata]: > `foldr c n [] = n`! I am a fool! That said, we could make an optimization flag, and maybe include it in -O2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 20:05:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 20:05:33 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.474f4c9cb7b287ef66cb765c7381602c@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): Not sure what you mean. An optimization flag that changes whether `cycle []` is an error or nontermination? I don?t think this is a good idea. Anyways, as you said: It is more important that `cycle` is a good producer. I don?t see how an enclosing `foldr` would get in touch with the `augment` in `let cyc = augment cycle' cyc in cyc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 20:44:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 20:44:45 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string In-Reply-To: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> References: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> Message-ID: <060.8de03e30a0ce1d12f2a626f4660069f9@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): OK, it's a little trickier than just specifying a new format string; I forgot that {{{ #include "stdio.h" int main() { printf("%.*s", 4, "AA\0B"); return 0; } }}} only outputs AA, even with the length description. So we can't use debugBelch. This raises the question, why are we using debugBelch at all? Some archaeology later: {{{ [project @ 2005-01-28 23:33:57 by krasimir] - The output from uncaught exceptions handler is redirected to RTS's errorBelch. - The output from Debug.Trace is redirected to RTS's debugBelch - Usually errorBelch and debugBelch messages go to stderr except for Windows GUI applications. For GUI applications the Debug.Trace output is redirected to debug console and the exceptions message is displayed in message box. }}} It also seems like a good idea generally to bypass Haskell-lands buffering. Unfortunately, printf style output is a hard-coded assumption for `RtsMsgFunction`, so we can't easily swap it out without introducing another function for raw output. Maybe, alternately, Debug.Trace should munge out null bytes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 20:56:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 20:56:35 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.7ce1b6a4bc8b410f1dc9e2dedfbcfd5a@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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 think you need to move the knot-tying into the argument to build, e.g. something like {{{ cycle xs = build $ \c _ -> let cyc = foldr c cyc xs in cyc }}} (ignoring the issue of `cycle []` for now) It seems that this would be both a good produce, and possibly even a good consumer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 21:55:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 21:55:20 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.1b825f2d7f79f51210f0c92174aae597@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:12 nomeata]: > I think you need to move the knot-tying into the argument to build, e.g. something like > {{{ > cycle xs = build $ \c _ -> let cyc = foldr c cyc xs in cyc > }}} > (ignoring the issue of `cycle []` for now) > > It seems that this would be both a good producer, and possibly even a good consumer. I won't be able to test anything for some hours, but that does look very promising indeed. I wonder if GHC performed some transformation that turned mine into yours somehow, but yours is definitely much clearer and prettier in any case. I ''think'' it's a good producer, and a good consumer for `build`. It doesn't look like a perfect consumer for `augment` (although it's not a ''bad'' one), but that may be unavoidable. I believe `cycle` is one of the more popular list functions in production code, so personally I think it's probably worth giving up the error message on a null argument to buy a little performance, even on the consumption side, but it's also true that the production side is more important in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 22:08:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 22:08:08 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.9457898ae6d99352e3cb42516c2cba71@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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 isaacdupree): In compiled code, the latter definition throws <>, which is nice. Try `runghc test.hs` (nontermination) vs `ghc test.hs && ./test` (exception): {{{ import GHC.Exts cycle2 xs = build $ \c _ -> let cyc = foldr c cyc xs in cyc main = print (cycle2 [] !! 0 :: Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 3 22:41:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Aug 2014 22:41:24 -0000 Subject: [GHC] #9403: Make --show-iface more human readable Message-ID: <045.f0b2674a7f3436fd6b9bb7526a38ea78@haskell.org> #9403: Make --show-iface more human readable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Right now --show-iface is not particularly interpretable, even if you are looking at the Outputable instance for `ModIface`. The problem seems to be the output for `mi_deps`, `mi_usages`, `mi_decls`, `mi_insts`, `mi_fam_insts` and `mi_rules` is not clearly delimited, making it unclear (for example) what `import -/ base:Prelude HASH` refers to unless you already happen to know that this must be from `mi_usages`. It should be relatively easy to improve this, but I want to make sure people who rely on this output aren't blindsided by the changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 01:22:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 01:22:36 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters Message-ID: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- In trying to understand the algorithm implemented in !TcExpr, I've spent some time examining `tcInferRho`. I conjecture that this function is superfluous and should be removed, in favor of `tcInfer . tcExpr`. Some of these thoughts were first written up in [http://www.haskell.org/pipermail /ghc-devs/2014-July/005733.html this thread]. After a considerable amount of staring, I've actually found a misbehavior caused by the current implementation. `tcInferRho` calls `tcInfExpr`, which has only 3 special cases before calling `tcInfer . tcExpr`: for variables, parentheses, and application. I was first drawn into this problem because these three cases seem woefully insufficient for the problem at hand. I was surprised how such a paucity of cases could have survived without causing havoc, if indeed `tcInferRho` were necessary at all. For example, only normal (prefix) application is handled; infix application is missing. In looking at differences between `tcInferApp` (which is called from the application case of `tcInfExpr`) and `tcApp` (called from `tcExpr`), I saw that the former doesn't have a special case for `seq` while the latter does. And, indeed, this difference is exploitable. This compiles fine: {{{ foo _ = case () `seq` (# #) of (# #) -> () }}} This does not: {{{ foo _ = case seq () (# #) of (# #) -> () }}} which produces {{{ Scratch.hs:15:21: Kind incompatibility when matching types: b0 :: * (# #) :: # In the second argument of ?seq?, namely ?(##)? In the expression: seq () (##) }}} Looking at the code, this behavior is expected, because the first version of the code calls into `tcInfer . tcExpr`, which special-cases `seq`, while the second is caught by `tcInferApp`, which doesn't have the special case. The above example shows that this isn't just a theoretical concern about code cleanup! This all leads to another question: Why special-case `seq` at all? !MkId tells me that {{{ seq :: forall (a :: *) (b :: *). a -> b -> b }}} Why isn't it {{{ seq :: forall (a :: *) (b :: OpenKind). a -> b -> b }}} With the second type, I would imagine that `seq` wouldn't need a special case in the type-checker. Is there something wrong with the second type for `seq`? I'll post more thoughts to this ticket as I continue to explore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 01:34:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 01:34:23 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.c57d21b1251ecc21ad9d5e6ba3ba29b1@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): I've tried removing `tcInfExpr`, in favor of having `tcInferRhoNC` call `tcExpr` directly. I'll post here once I see how it goes. I didn't find other special cases worth mentioning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 02:22:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 02:22:10 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.f8cedc6702889b05fbb90d156faeea59@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- 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: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by rwbarton: Old description: > (Spawned from #9370; see there for original discussion) > > Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and > remove the `OPTIONS_GHC` line at the top of the file that disables > optimizations and build with `cabal buidl`. Then GHC takes ~1.5GB and > over a minute to build this single module. > > Preliminary investigation indicates that Text's fromString and its > constituent parts is being inlined repeatedly: > {{{ > 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 ] > }}} > resulting in a very large intermediate program: > {{{ > *** 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} > ... > }}} New description: (Spawned from #9370; see there for original discussion) Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl`. Then GHC takes ~1.5GB and over a minute to build this single module. Preliminary investigation indicates that Text's fromString and its constituent parts is being inlined repeatedly: {{{ 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 ] }}} resulting in a very large intermediate program: {{{ [ 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,806, types: 14,467, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 31,052, types: 20,719, coercions: 0} Result size of Simplifier = {terms: 31,052, types: 20,719, coercions: 0} *** Specialise: Result size of Specialise = {terms: 32,254, types: 22,696, coercions: 448} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 63,022, types: 59,045, coercions: 448} *** Float inwards: Result size of Float inwards = {terms: 63,022, types: 59,045, coercions: 448} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 28,537, types: 18,902, coercions: 654} Result size of Simplifier iteration=2 = {terms: 28,157, types: 18,257, coercions: 152} Result size of Simplifier iteration=3 = {terms: 28,074, types: 18,128, coercions: 140} Result size of Simplifier iteration=4 = {terms: 28,068, types: 18,096, coercions: 61} Result size of Simplifier = {terms: 28,068, types: 18,096, coercions: 61} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 43,941, types: 38,325, coercions: 61} Result size of Simplifier = {terms: 43,941, types: 38,325, coercions: 61} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 689,670, types: 461,960, coercions: 146,725} ... }}} [Edited: old output was not actually for `-O1` as described, but rather for the sequence described in #9370 of building with `-O0` after building another module with `-O1`.] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 03:23:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 03:23:40 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.31f3582cf92aeecf75449fb6177728e7@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: OK this is a bit funny. Normally a Text literal `"abc"` gets desugared as {{{ fromString $fIsStringText (unpackCString# "abc"#) }}} Now `fromString $fIsStringText = pack`, and `pack = unstream . S.map safe . S.streamList`, and there is a rule in `Data.Text` {{{ {-# RULES "TEXT literal" forall a. unstream (S.map safe (S.streamList (GHC.unpackCString# a))) = unpackCString# a #-} }}} and `Data.Text.unpackCString#` has a NOINLINE pragma so we end up with the nice small code: `Data.Text.unpackCString# "abc"`. ''But'', a ''single-character'' literal `"a"` is instead desugared as {{{ fromString $fIsStringText (: (C# 'a') ([])) }}} and now there is no rule which matches this pattern. And `unstream` is marked `INLINE [0]`, as Simon predicted; and it's rather large. And most XML entities represent single Unicode characters, so GHC generated around 2000 copies of `unstream`. I don't know why there is an `INLINE` pragma on `unstream`. Perhaps no good reason. But anyways, there is a simple fix to the text package: add another rule to match the pattern `unstream (S.map safe (S.streamList [c]))`. (And similarly for empty string literals.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 05:11:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 05:11:51 -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.b7aae27cf7a9b3825393ef8c102ce530@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 rwbarton): (For anyone who is paying careful attention to #9400 and is wondering why we have ~4000 identical inlinings here while in that ticket we have only ~2000 copies of `unstream`, the reason is that here we are building with `-O0`, so we do not process the rule which rewrites `Data.Text.pack . unpackCString#` to `Data.Text.unpackCString#`! The text library does not expect its users to follow its INLINE directives without also following its RULES.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 06:45:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 06:45:24 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.11719060f963ac4f70f5ec78e1e32c0c@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:12 nomeata]: I wrote some test functions, using the type {{{#!hs type BuildArg a = forall b . (a -> b -> b) -> b -> b }}} Generally things look pretty good (lots of Core to look at below, along with comments you should take with a grain of salt since I'm just a newbie). I found one case where your definition works significantly worse than the Prelude's. The bad case I've found: {{{#!hs main = print $ foldr (+) 0 $ take 30000000 $ map (* 13) $ cycle [1,8,4,0,(5::Int)] }}} For some reason, your `cycle` implementation allocates a lot, but the Prelude one runs in constant space. The basic test translations: {{{#!hs cycleBuild :: BuildArg a -> [a] cycleBuild g = cycle (build g) }}} produces {{{#!hs cycleBuild cycleBuild = \ @ a_a3jG g_a3hO -> letrec { cyc_a2iD cyc_a2iD = g_a3hO (:) cyc_a2iD; } in cyc_a2iD }}} which is obviously good, and obviously better than the result with `Prelude.cycle`, which is {{{#!hs cycleBuild cycleBuild = \ @ a_a1Xy g_a1zF -> case g_a1zF (:) ([]) of wild_a2aX { [] -> cycle1; : ipv_a2b3 ipv1_a2b4 -> letrec { xs'_a2b1 xs'_a2b1 = ++ wild_a2aX xs'_a2b1; } in xs'_a2b1 } }}} {{{#!hs cycleAugment :: BuildArg a -> [a] -> [a] cycleAugment g xs = cycle (augment g xs) }}} produces {{{#!hs cycleAugment cycleAugment = \ @ a_a3j1 g_a3hS xs_a3hT -> letrec { cyc_a2iD cyc_a2iD = g_a3hS (:) (++ xs_a3hT cyc_a2iD); } in cyc_a2iD }}} which I think is likely the best we can do, and clearly better than what the Prelude gives: {{{#!hs cycleAugment cycleAugment = \ @ a_a1WT g_a1zJ xs_a1zK -> case g_a1zJ (:) xs_a1zK of wild_a2aX { [] -> cycle1; : ipv_a2b3 ipv1_a2b4 -> letrec { xs'_a2b1 xs'_a2b1 = ++ wild_a2aX xs'_a2b1; } in xs'_a2b1 } }}} {{{#!hs foldCycleBuild :: (a -> b -> b) -> b -> BuildArg a -> b foldCycleBuild c n g = foldr c n (cycle (build g)) }}} produces {{{#!hs foldCycleBuild foldCycleBuild = \ @ a_a3jl @ b_a3jm c_a3hP _ g_a3hR -> letrec { cyc_a2iD cyc_a2iD = g_a3hR c_a3hP cyc_a2iD; } in cyc_a2iD }}} which is obviously good, and ''incomparably'' better than what the Prelude gives, which I will not paste here because it is very obviously very much inferior. The rest of the tests are a little harder for me to interpret, because the nested letrecs confuse me, but I think they're probably good too. {{{#!hs foldCycle c n xs = foldr c n (cycle xs) }}} produces {{{#!hs $wfoldCycle $wfoldCycle = \ @ a_a3lf @ b_a3lg w_s3mE w1_s3mG -> letrec { cyc_a2iD cyc_a2iD = letrec { go_a2GG go_a2GG = \ ds_a2GH -> case ds_a2GH of _ { [] -> cyc_a2iD; : y_a2GM ys_a2GN -> w_s3mE y_a2GM (go_a2GG ys_a2GN) }; } in go_a2GG w1_s3mG; } in cyc_a2iD foldCycle foldCycle = \ @ a_a3lf @ b_a3lg w_s3mE _ w2_s3mG -> $wfoldCycle w_s3mE w2_s3mG }}} {{{#!hs foldCycleAugment :: (a -> b -> b) -> b -> BuildArg a -> [a] -> b foldCycleAugment c n g xs = foldr c n (cycle (augment g xs)) }}} produces {{{#!hs $wfoldCycleAugment $wfoldCycleAugment = \ @ a_a3hx @ b_a3hy w_s3mD w1_s3mF w2_s3mG -> letrec { cyc_a2iD cyc_a2iD = w1_s3mF w_s3mD (letrec { go_a2GG go_a2GG = \ ds_a2GH -> case ds_a2GH of _ { [] -> cyc_a2iD; : y_a2GM ys_a2GN -> w_s3mD y_a2GM (go_a2GG ys_a2GN) }; } in go_a2GG w2_s3mG); } in cyc_a2iD foldCycleAugment foldCycleAugment = \ @ a_a3hx @ b_a3hy w_s3mD _ w2_s3mF w3_s3mG -> $wfoldCycleAugment w_s3mD w2_s3mF w3_s3mG }}} which I have no idea what to think of, honestly. {{{#!hs mapCycle f xs = map f (cycle xs) }}} produces {{{#!hs mapCycle mapCycle = \ @ a_a3lA @ b_a3lB f_a3hJ xs_a3hK -> letrec { cyc_a2iD cyc_a2iD = letrec { go_a2GG go_a2GG = \ ds_a2GH -> case ds_a2GH of _ { [] -> cyc_a2iD; : y_a2GM ys_a2GN -> : (f_a3hJ y_a2GM) (go_a2GG ys_a2GN) }; } in go_a2GG xs_a3hK; } in cyc_a2iD }}} which looks sane enough?it just maps over `xs` and then cycles the result. I also took a look at {{{#!hs cycleMap f xs = cycle (map f xs) }}} This produced exactly the same Core, which I think is a positive sign. The Prelude implementation, on the other hand, gives a rather terrible result: {{{#!hs mapCycle mapCycle = \ @ a_a2aw @ b_a2ax f_a1x7 xs_a1x8 -> case xs_a1x8 of wild_a2aV { [] -> case cycle1 of wild1_00 { }; : ipv_a2b1 ipv1_a2b2 -> letrec { xs'_a2aZ xs'_a2aZ = ++ wild_a2aV xs'_a2aZ; } in map f_a1x7 xs'_a2aZ } }}} Yes, it actually cycles the argument and then maps over the result?horrible in every way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 07:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 07:16:06 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.d8a17985a335f562a858e41b5b041b83@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): > Yes, it actually cycles the argument and then maps over the result?horrible in every way. But this is well-known: You usually cannot ?modify? cyclic data structures without breaking them. Of course its cool that with the above definition of `cycle` + fusion, we can suddenly `map` over a cyclic structure without breaking it, but maybe that?s a tad too much magic? Especially as people probably don?t have a good feeling for when this happens and when not? OTOH, I don?t think it hurts either, and nice surprises are ? well ? nice. Did you investigate why `foldr (+) 0 $ take 30000000 $ map (* 13) $ cycle [1,8,4,0,(5::Int)]` allocates more? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 08:15:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 08:15:52 -0000 Subject: [GHC] #9401: MVar deadlock exceptions cause exceptions in later MVar ops In-Reply-To: <047.dff103cf5d7e0b589e93e503e1de6184@haskell.org> References: <047.dff103cf5d7e0b589e93e503e1de6184@haskell.org> Message-ID: <062.3478d7ec1bfd28e740a5d92fad3cb3fa@haskell.org> #9401: MVar deadlock exceptions cause exceptions in later MVar ops -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: invalid | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: This isn't a bug. There are two threads: the main thread, blocked in readMVar, and the child thread, blocked in takeMVar. BOTH threads are deadlocked, so the RTS sends them both an exception. It has no way to tell that unblocking the child thread would later allow the main thread to make progress, or indeed whether the reverse might be true. So the rule is simple: when there are a group of deadlocked threads, they are all sent an exception simultaneously. There's a similar example in my book, [http://chimera.labs.oreilly.com/books/1230000000929/ch15.html#sec_deadlock], see `deadlock1.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 08:23:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 08:23:22 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.f441a8617f6594d67e0164aee6ac72d3@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:16 nomeata]: > > Yes, it actually cycles the argument and then maps over the result?horrible in every way. > > But this is well-known: You usually cannot ?modify? cyclic data structures without breaking them. > > Of course its cool that with the above definition of `cycle` + fusion, we can suddenly `map` over a cyclic structure without breaking it, but maybe that?s a tad too much magic? Especially as people probably don?t have a good feeling for when this happens and when not? OTOH, I don?t think it hurts either, and nice surprises are ? well ? nice. Well, I agree that magic can be a problem, but if it falls out of something that tends to be good, that's not a major issue. > Did you investigate why `foldr (+) 0 $ take 30000000 $ map (* 13) $ cycle [1,8,4,0,(5::Int)]` allocates more? I'm not entirely sure, but it looks to me like it's all about unboxing. Somehow, the Prelude version is able to unbox all the `Int`s, whereas this one is not. If I replace the `(+)` with {{{#!hs {-# NOINLINE g #-} g a b = a }}} then both versions run in constant space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 08:53:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 08:53:08 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.17910f365a3aedcd53734c8cf15efd19@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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:16 nomeata]: OK, thinking about this more clearly, I think I see some things I did not realize before, and I am less and less confident that any of this was a good idea. Aside from the magical map, and the pleasantness of the form when fused on both sides, I think this whole thing probably does more harm than good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 09:20:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 09:20:59 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.de53875bb46846b52c3a787880ac86b9@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): Don?t be discouraged! I think this is very much worth it, and if people use `cycle` in list comprehensions (which they likely do), there might be real-world benefit in this. We just need to avoid regressions. I tried to reproduce your findings. I do observe the higher allocation, but the accumulator `Int#` is still unboxed. The extra allocations seem to stem from the `ys1` allocated here: {{{ Rec { go :: [GHC.Types.Int] -> GHC.Prim.Int# -> GHC.Types.Int go = \ (ds :: [GHC.Types.Int]) -> case ds of _ { [] -> Main.main_cyc; : y ys -> let { ys1 :: GHC.Prim.Int# -> GHC.Types.Int ys1 = go ys } in \ (eta :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# (GHC.Prim.<=# eta 1) of _ { GHC.Types.False -> case y of _ { GHC.Types.I# x -> case ys1 (GHC.Prim.-# eta 1) of _ { GHC.Types.I# y1 -> GHC.Types.I# (GHC.Prim.+# (GHC.Prim.*# x 13) y1) } }; GHC.Types.True -> case y of _ { GHC.Types.I# x -> GHC.Types.I# (GHC.Prim.*# x 13) } } } Main.main_cyc :: GHC.Prim.Int# -> GHC.Types.Int Main.main_cyc = go lvl9 end Rec } }}} This is an interesting case. It seems to be a shortcoming in the call arity analysis: One might think it should be able to infer that `go` is always called with two arguments (and hence move the `\eta` out of the `let` and `case`). But it (rightfully) doesn?t do that because `main_cyc` is a thunk, and eta-expanding it would duplicate the case analysis done by `case ds`. The regular arity analysis also refuses to improve that code, for a similar reason: It considers to move the `\eta` up, but it would escape the `let ys1`, and the arity analysis is unable to determine if that would be expensive or not. Interesting case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 09:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 09:40:05 -0000 Subject: [GHC] #9403: Make --show-iface more human readable In-Reply-To: <045.f0b2674a7f3436fd6b9bb7526a38ea78@haskell.org> References: <045.f0b2674a7f3436fd6b9bb7526a38ea78@haskell.org> Message-ID: <060.55b65039cca2628708355d4d2854ad05@haskell.org> #9403: Make --show-iface more human readable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it! I doubt that anyone relies on the syntactic form of the output of `--show-iface` Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 09:46:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 09:46:37 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.769d2a0f139f6246be0285a38e9d814f@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Another possibility might be to remove the special behaviour of desugaring strings from GHC. Why is it there? I think it's in case you do {{{ case "x" of 'x' : ys -> blah }}} or something like that. But perhaps a better plan would be to make `unpackCString# "foo"` respond to `exprIsConApp_maybe` with "yes, I'm a cons; my head is `'f'` and my tail is `unpackCString# "oo"`. So before making `Text` more complicated, maybe we should explore making GHC less complicated! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 09:58:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 09:58:19 -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.d16a9468c1badfc8effc1991c191c852@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 simonmar): Simon: so long as the foreign call is treated as having side effects etc. by the simplifier, it should be OK. I think this code dates back to the original implementation of foreign calls and has only had shallow modifications since then (indeed if you look at `git blame` some of the code is very old), it's entirely possible it can be refactored to be simpler. One thing to watch out for is that `resultWrapper` is called from the translation for `CLabel` (i.e. `foreign import "&foo"`) wheras `boxResult` is called from the translation for `foreign import`. I'm not sure whether that's significant or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 10:40:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 10:40:44 -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.eb566811216963f63c8da022e00b6d10@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): Replying to [comment:15 rwbarton]: > The text library does not expect its users to follow its INLINE directives without also following its RULES.) And THAT is the GHC bug here: we are compiling a client with `-O0` but * we ''are'' obeying INLINE pragmas from `Text`, * we ''are not'' obeying RULES from `Text`. Right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 10:57:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 10:57:39 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.0f1de4615215988fd330329519ee8a3a@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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): Staring at this case a bit more, I conclude that we will never get good code from fusing a higher order foldr (like `foldl` or `take` or anything with an accumulating parameter) with a cyclic producer. It will sucessfully tie the know, but a knot of type `Int# -> Int` (and we can see this happening here). So it will create 5 function closures of that type that call each other in a round-robin style; the pattern match on the list elements happens only once. And I as there is no way to pull the accumulating argument into the knot (after all, it changes while going round the circle), this can hardly be avoided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:12:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:12:58 -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.7436cc9ff774533962defa1fb1ddea9d@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 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"44853a157a394bf00d1fdfff1926a6d178d8018c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="44853a157a394bf00d1fdfff1926a6d178d8018c" Terminate in forkProcess like in real_main Test Plan: validate Reviewers: simonmar, austin Reviewed By: simonmar, austin Subscribers: phaskell, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D99 GHC Trac Issues: #9377 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:21:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:21:16 -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.fa7d607e79b35368ca6be55577ea74f0@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: closed Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (NCG) | Keywords: Resolution: fixed | 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 thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:21:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:21:41 -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.20527cc4827e1491b98b87d151d03789@haskell.org> #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: fixed | 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 thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:21:56 -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.1db571b0b192d57d59254d560597720e@haskell.org> #9379: Blocked STM transaction is not interruptible -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Runtime | Version: 7.8.3 System | 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: | https://phabricator.haskell.org/D104| -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:36:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:36:50 -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.7ae4c76f1a21d751022e2e56fab3ba73@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): Great. Herbert: would you like to proceed with this refactoring? I can help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:43:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:43:10 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.a15664928fe63ddcb9d8eace4100ac24@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: floating point 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 thoughtpolice): I'm taking a look at these patches now to see if I can figure out the issue with the first one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:48:02 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.d0b7a8654d9ec372a873c54a2f6740fd@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to add a bit more detail: * The special handling for singleton string literals is in `MkCore.mkStringExprFS`. Omittign the `lengthFS str == 1` case looks very plausible to me. * Notice that this same function sometimes generates `unpackCStringUtf8` rather than `unpackCString`. Rules that recognise only the latter will stumble if the former is produced. I have no clue what to do about this -- Unicode experts may. * The function `CoreSubst.exprIsConApp_maybe` is the place where we say "does this expression look like a constructor application?". Adding an extra case to `go`, below the ones for `dataConWorkId` and `DFunFunfolding` should let us dynamically expand a call to `unpackCString` into a cons cell. And that will actually be ''better'' than now, because it should eliminate {{{ case "foo" of 'f' : 'o' : xs -> .... }}} Would someone care to try? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:49:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:49:42 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.be10625acae33b1493498d4f2581f5cf@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #9238 Comment: Oh I know why. See #9238. `signum` looks something like {{{ \(D# x) -> case x of { __DEFAULT__ -> ... 0.0 -> x } }}} and at `-O1` and higher, `x` is inlined to `0` in the right-hand side of the second case alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 13:50:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 13:50:22 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.dac2ef0e36cbff4b2a4b34158f0ce8a4@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: #7858 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #7858 Comment: This arose also in #7858. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 14:20:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 14:20:50 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.59ae6f627601238e2f2e2085f3a9b929@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 simonpj]: > Another possibility might be to remove the special behaviour of desugaring strings from GHC. Why is it there? I was guessing that perhaps the generated code is smaller for a one- character list than for a call to `unpackCString#`. But if that's true, it's not a very good reason to put that logic in the desugarer; we could rewrite `unpackCString# "a"` to `'a' : []` in a later optimizer pass, after RULES have fired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 14:31:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 14:31:33 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.7d6e9b6c32a2240a176a2f3f16b11ed1@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 14:36:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 14:36:52 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.56248ae66e76e6d1afa79b2cf9fb2508@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: => 7.10.1 Comment: We can replace the expensive `isNegativeZero x` test in `abs` with `x == 0`, since `abs` of positive zero is also zero. {{{ abs x | x == 0 = 0 | x >= 0 = x | otherwise = negate x }}} Of course this merits a comment on the first guard! As for `signum`, I don't see off-hand a simple way to work around the bug #9238, so I suggest we apply the `abs` patch, then mark this ticket as blocked by #9238. If someone gets around to implementing efficient `abs` and `signum` with fancy bit tricks before 7.10 then it will become moot anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 14:49:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 14:49:47 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.118a243f4b5e7f1e0556129321931c46@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: non-existant-user Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 3658 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: thoughtpolice => non-existant-user -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 14:50:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 14:50:03 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.fee1eb7b6e33a1959d573fc4bf461613@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 3658 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: non-existant-user => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 15:01:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 15:01:55 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) Message-ID: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- After talking with Simon & Simon today, we discussed ticky profiling, and it dawned on us that ticky probably isn't reported when the program is interrupted via the user. But it should be! The motivating case is when you're dealing with an infinite loop and you want to find the binding that has a high entry count (i.e. it's the looping body). But the only way to move forward is to interrupt it, which doesn't spit out the reports. Fixing this would make ticky much more useful in such cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 15:06:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 15:06:26 -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.5fdfbaf4a460dce3b80ccb3f07d3e599@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 rwbarton): In the case that originated this ticket, yes. In general, the bug is that whether we obey INLINE pragmas in an imported module M depends not just on the optimization flags in effect for the module we are currently compiling, but also on the optimization flags that were in effect for the first module in this `ghc --make` invocation that imported M. (Or that caused GHC to load the interface file for M for any reason, if that ever happens other than because M was imported.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 16:14:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 16:14:42 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.c07ef99807ac1ed6cb50692f4d360cc8@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Actually, how about this for signum? {{{ signum :: Double -> Double signum x | x > 0 = 1 | x < 0 = negate 1 | otherwise = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 16:41:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 16:41:34 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.e2e0939cf5ce7beb5d6b69432982cb9a@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: 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 Dzhus): * cc: dima@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 18:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 18:13:15 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.b5bb3a828455822dbc7c258d720c01d4@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D119 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 18:13:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 18:13:23 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.73b6b4675a9e772ea1708826e447462c@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): if we had a cheap Float<->Word32, Double <-> Word64, could we define these wrt the bit banging approach? In fact, can't we define those already using CMM (wrt the unlifted types)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 18:56:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 18:56:45 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.e2e401f1e22428746128447977fccb64@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:8 carter]: > if we had a cheap Float<->Word32, Double <-> Word64, could we define these wrt the bit banging approach? In fact, can't we define those already using CMM (wrt the unlifted types)? Well, on x86, ideally we would use `andps`/`andpd` for `abs`, and stay within the SSE register set. I don't know what is the most efficient way to implement `signum`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 19:49:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 19:49:34 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled In-Reply-To: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> References: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> Message-ID: <059.ec4c065e1d38e1556311cbd43d93c780@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: pthread staticlib Operating System: MacOS X | threaded Type of failure: Compile- | Architecture: x86 time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by etrepum): https://phabricator.haskell.org/D120 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 19:53:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 19:53:05 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled In-Reply-To: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> References: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> Message-ID: <059.4b12927e6d8b5c77cf00fc64150a44b6@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: pthread staticlib Operating System: MacOS X | threaded Type of failure: Compile- | Architecture: x86 time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by etrepum): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 22:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 22:29:26 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) Message-ID: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: T7837 | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: T7837 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This may be a test suite configuration error as the normal case works. When run with an llvm-perf build of the HEAD, I get: {{{ =====> T7837(normal) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/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 -c T7837.hs -O -ddump-rule-firings >T7837.comp.stderr 2>&1 =====> T7837(profasm) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/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 -c T7837.hs -O -prof -static -auto-all -O -ddump-rule- firings >T7837.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./indexed-types/should_compile/T7837.stderr 2014-08-03 11:36:53.000000000 +0100 +++ ./indexed-types/should_compile/T7837.comp.stderr 2014-08-04 23:16:34.000000000 +0100 @@ -1,3 +1,4 @@ Rule fired: Class op abs Rule fired: Class op signum Rule fired: normalize/Double +Rule fired: Class op / *** unexpected failure for T7837(profasm) Unexpected results from: TEST="T7837" OVERALL SUMMARY for test run started at Mon Aug 4 23:16:32 2014 BST 0:00:02 spent to go through 4068 total tests, which gave rise to 19536 test cases, of which 19534 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures Unexpected failures: indexed-types/should_compile T7837 [stderr mismatch] (profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 4 22:36:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Aug 2014 22:36:31 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.331351b9f19f58dbb2cb5399fce96b5b@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: T7837 Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: T7837 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jrp: Old description: > This may be a test suite configuration error as the normal case works. > When run with an llvm-perf build of the HEAD, I get: > > {{{ > =====> T7837(normal) 1395 of 4068 [0, 0, 0] > cd ./indexed-types/should_compile && > '/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 -c T7837.hs -O -ddump-rule-firings >T7837.comp.stderr > 2>&1 > =====> T7837(profasm) 1395 of 4068 [0, 0, 0] > cd ./indexed-types/should_compile && > '/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 -c T7837.hs -O -prof -static -auto-all -O -ddump-rule- > firings >T7837.comp.stderr 2>&1 > Actual stderr output differs from expected: > --- ./indexed-types/should_compile/T7837.stderr 2014-08-03 > 11:36:53.000000000 +0100 > +++ ./indexed-types/should_compile/T7837.comp.stderr 2014-08-04 > 23:16:34.000000000 +0100 > @@ -1,3 +1,4 @@ > Rule fired: Class op abs > Rule fired: Class op signum > Rule fired: normalize/Double > +Rule fired: Class op / > *** unexpected failure for T7837(profasm) > > Unexpected results from: > TEST="T7837" > > OVERALL SUMMARY for test run started at Mon Aug 4 23:16:32 2014 BST > 0:00:02 spent to go through > 4068 total tests, which gave rise to > 19536 test cases, of which > 19534 were skipped > > 0 had missing libraries > 1 expected passes > 0 expected failures > > 0 caused framework failures > 0 unexpected passes > 1 unexpected failures > > Unexpected failures: > indexed-types/should_compile T7837 [stderr mismatch] (profasm) > }}} New description: This may be a test suite configuration error as the normal case works (and indeed I get a lot of profiled case failures of other cases). When run with an llvm-perf build of the HEAD, I get: {{{ =====> T7837(normal) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/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 -c T7837.hs -O -ddump-rule-firings >T7837.comp.stderr 2>&1 =====> T7837(profasm) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/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 -c T7837.hs -O -prof -static -auto-all -O -ddump-rule- firings >T7837.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./indexed-types/should_compile/T7837.stderr 2014-08-03 11:36:53.000000000 +0100 +++ ./indexed-types/should_compile/T7837.comp.stderr 2014-08-04 23:16:34.000000000 +0100 @@ -1,3 +1,4 @@ Rule fired: Class op abs Rule fired: Class op signum Rule fired: normalize/Double +Rule fired: Class op / *** unexpected failure for T7837(profasm) Unexpected results from: TEST="T7837" OVERALL SUMMARY for test run started at Mon Aug 4 23:16:32 2014 BST 0:00:02 spent to go through 4068 total tests, which gave rise to 19536 test cases, of which 19534 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures Unexpected failures: indexed-types/should_compile T7837 [stderr mismatch] (profasm) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 03:25:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 03:25:38 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O Message-ID: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiled and run as {{{ ghc Subtlety.hs Subtlety }}} the attached program generates the correct output of {{{ Just (Vec3 0.0 0.0 1.0) }}} but when compiled and run using {{{ ghc -O Subtlety.hs Subtlety }}} the program's output is {{{ Just (Vec3 0.0 0.9805806756909202 0.19611613513818404) }}} Furthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program. I am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 04:22:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 04:22:36 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.a69e5d02a8549560624601951d7a7a9f@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): How odd. I can't reproduce on GHC 7.8.3 x86-64 on Debian. Note that the output of the optimized program is `normalized (Vec3 0 5 1)`, so it looks like some of the x/y/z-coordinates are getting mixed up somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 04:27:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 04:27:29 -0000 Subject: [GHC] #9408: Guidelines For Proper Body Building Message-ID: <050.bfad9793d99c86412f490ded07e7b0d6@haskell.org> #9408: Guidelines For Proper Body Building -------------------------------------+------------------------------------- Reporter: amosgene007 | 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 game of construction yobo has been around for quite many example now, with ability and subject expanding the have to new place with each future decennium. But as bailiwick reveals writer and much facts nigh sinew edifice, there is more for beginners to acquire. In burden, there are cardinal aspects to maintain in aim: correct workout activity, nutrition, and relaxation. [http://testcorepromuscleuk.com/ Testcore Pro] The prototypical aim to writing is nutrition. Without proper caloric intake and nutrients, there faculty be very short goodness in alter the most tight of workout exercises. To fully stomach plus of a workout lesson, one must consumer sufficiency carbohydrates and proteins to permit the body to frame many yobbo. Unrefined foods such as red meat, poulet, beans, and equal tike butter and types of nuts module somebody enough accelerator values. Of bed with fair nutrition and lay, there isn't more of a amount for business ruffian! Exact tough building exercises should be performed after a tremendous intake of catalyst. It is chief to stronghold hydrated in this punctuation, so bully can be improved rather than damaged. More posture grooming exercises give let cloudy lifting, though a trainer faculty eff the unexceeded exercises for muchRelief is ofttimes overlooked in the outgrowth, but it plays a indispensable persona in antiquity hooligan. It is generally thoughtful pattern for a body stuff to eff 8 hours of nap apiece night. Most embody builders present also compound naps into their daily turn, with breaks beingness observed as shortly as justness after a workout. This gives the muscles a hazard to turn and produce, and thusly, the resting present is really weighty.There is e'er second for a goodness comedian grooming meeting, but it should be noted that it is really thinkable to teach too such. Breeding too some testament put unnecessary strain on the muscles beingness targeted, and this can strip to bully debasement. This faculty return results rather than hit improvements, and thus, suitable sleep and slackening should be observed. If one seems to be waking up with an exhausted opinion each day, it would be a majuscule air to affirm those with saintly motive shouldn't individual to disquiet nearly it, it is fundamental that steroids and else illicit substances not be old in one's training software. The substances such as steroids provide unsporting advantages, but also author importantly can individual strict welfare risks. And because they are indeed outlawed from more sports and institutions, using much drugs present straighten trainees nonresistant for disqualification in rivalry. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 04:35:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 04:35:01 -0000 Subject: [GHC] #9408: Guidelines For Proper Body Building In-Reply-To: <050.bfad9793d99c86412f490ded07e7b0d6@haskell.org> References: <050.bfad9793d99c86412f490ded07e7b0d6@haskell.org> Message-ID: <065.a7b4a42d90bb944e5e630239cc6509e0@haskell.org> #9408: Guidelines For Proper Body Building -------------------------------------+------------------------------------- Reporter: | Owner: amosgene007 | 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 Fuuzetsu: Old description: > The game of construction yobo has been around for quite many example now, > with ability and subject expanding the have to new place with each future > decennium. But as bailiwick reveals writer and much facts nigh sinew > edifice, there is more for beginners to acquire. In burden, there are > cardinal aspects to maintain in aim: correct workout activity, nutrition, > and relaxation. > [http://testcorepromuscleuk.com/ Testcore Pro] > The prototypical aim to writing is nutrition. Without proper caloric > intake and nutrients, there faculty be very short goodness in alter the > most tight of workout exercises. To fully stomach plus of a workout > lesson, one must consumer sufficiency carbohydrates and proteins to > permit the body to frame many yobbo. Unrefined foods such as red meat, > poulet, beans, and equal tike butter and types of nuts module somebody > enough accelerator values. > Of bed with fair nutrition and lay, there isn't more of a amount for > business ruffian! Exact tough building exercises should be performed > after a tremendous intake of catalyst. It is chief to stronghold hydrated > in this punctuation, so bully can be improved rather than damaged. More > posture grooming exercises give let cloudy lifting, though a trainer > faculty eff the unexceeded exercises for muchRelief is ofttimes > overlooked in the outgrowth, but it plays a indispensable persona in > antiquity hooligan. It is generally thoughtful pattern for a body stuff > to eff 8 hours of nap apiece night. Most embody builders present also > compound naps into their daily turn, with breaks beingness observed as > shortly as justness after a workout. This gives the muscles a hazard to > turn and produce, and thusly, the resting present is really weighty.There > is e'er second for a goodness comedian grooming meeting, but it should be > noted that it is really thinkable to teach too such. Breeding too some > testament put unnecessary strain on the muscles beingness targeted, and > this can strip to bully debasement. This faculty return results rather > than hit improvements, and thus, suitable sleep and slackening should be > observed. If one seems to be waking up with an exhausted opinion each > day, it would be a majuscule air to affirm those with saintly motive > shouldn't individual to disquiet nearly it, it is fundamental that > steroids and else illicit substances not be old in one's training > software. The substances such as steroids provide unsporting advantages, > but also author importantly can individual strict welfare risks. And > because they are indeed outlawed from more sports and institutions, using > much drugs present straighten trainees nonresistant for disqualification > in rivalry. > http://testcorepromuscleuk.com/ New description: spam, delete me -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 05:43:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 05:43:49 -0000 Subject: [GHC] #9409: Bodybuilding Women Message-ID: <050.28232f103da998d6ab730a54e7e6f537@haskell.org> #9409: Bodybuilding Women -------------------------------------+------------------------------------- Reporter: amosgene007 | 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: -------------------------------------+------------------------------------- Steady if we lie support to the 1970s and 80s, piece women had already been making profound move in opposite comic, exercise was not considered as one of the most preferable things for any friend to persist. The domain was achievement finished a soundness turn, but it was console generally unheard of nigh a caucasian joining a gym. They could locomote their shape performance and training but that was mainly narrow to whatsoever basic freehand upbringing equivalent aerobics. Pulling weights was ease not in. A bit of travel and jogging was all that women were unsurprising to tackle. [http://testcorepromuscleuk.com/ Testcore Pro] The Change in NoesisIt was during the 1990s that a alter could be seen in the knowledge towards women bodybuilders and the athlete of Women Exercising. With many and more women joining the sportswoman and with accrued sort of events, shows and competitions being thrown area to them, women bodybuilders started to benefit wider approval for their skills and achievements. Success breeds success and with apiece productive event state hosted there was an accrued popularity for the diversion. The women athletes were now showered with the self politeness and admiration which until now was the mend perquisite of the men. Why should Women be in Exercise?The answer to this speculate is orbicular - "why not?" Piece umteen intellection that a woman's body is far too weak to go finished the stringent toil of the gym, such beliefs were idle. It staleness be comprehended that when men play bodybuilding, not all of them bed a similar physique. Every single is various and that warrants that they should bang variant training programs. But that does not think that exclusive those who are course stiff can or should try exercising. It is a sportsman where everyone can joint in and put in their champion. Patch one accepts that a woman's body in comparison to a man's body will generally be less hefty, yet it does not bang forth from the fact that any several who invests instance in workout will turn immensely. There are a few benefits of exercise that are coupling, no weigh whether you are a man or a female. When you are bodybuilding you are pinioned to get fitter and stronger. Your muscles gift be able to hold many say and you joints faculty get many elastic. Gross you faculty be a far better mortal than you were before you started musclebuilding. Musclebuilding also allows you to bang a such surmount style. Tho' it mightiness be a bit tall during the initial stages, formerly you get victimized to the manner of a mortal, with genuine dietetical habits, frequenter unerect hours and an coverall built way of living, you defense to clear a lot. Beyond the plain carnal gains, you will also look much comfy, more solon self-assured. You module be competent to engrossment on your job fitter, and your show give go up a cutting. Now that is a object lot of vantage for disagreeable bodybuilding. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 06:36:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 06:36:17 -0000 Subject: [GHC] #9410: Your Weight In Muscle Message-ID: <050.b67f5b1438aa88c1167a6003a98707f3@haskell.org> #9410: Your Weight In Muscle -------------------------------------+------------------------------------- Reporter: amosgene007 | 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: -------------------------------------+------------------------------------- You likely somebody heard that strength weighs author than fat. More fill notice a shrimpy coefficient realise when they solon lifting weights consistently. As a pervasive formula, if you transportation weights 2 to 3 present a hebdomad, you can acquire 1 thrust of strength per period for nigh 6 months. After that, the evaluate of growth slows medico as you act to reach your inheritable potential. For the homophonic grounds, you yearner you transportation; your progression will change because you are movement your heritable potency. [http://testcorepromuscleuk.com/ Testcore Pro] Don't be alarmed at the player pounds of unit from metric breeding because it is cured worth the try. For every 3 pounds of bully you bod, research shows you gain your resting metabolous value by nearly 7 percent. For representation, if your body comic 1,200 calories per day (not counting drill or any other move), you would hurting an thespian 84 calories per day with those 3 histrion pounds of yob. Umteen women score a problematical reading outgrowing 2-3 poke booby weights, because they are afeard that if they growth the weight they will figure up. If you are content with the power and appearance of your muscles, you can do a maintenance idea with 5 writer weights. Nevertheless, if you poorness author powerfulness, you could progress to 8 or 10 move weights and still not volume up. Using heavier weights can gain yobo situation, but it's highly remote that you'll get bulky. Women don't naturally get sufficiency of the corticosteroid, testosterone, required to form immense muscles, and regularise if you could bulk up, you'Another deciding to speech hooligan is to increase your repetitions instead of expanding weight. A high- repetition/light-weight document instrument develop sinew feel and increase capability and aliveness without significantly maximizing rowdy size. I similar to swear my clients to not retributory go finished the occurrence when lifting weights. I use the express try" a lot to draw the contraction of the bully you should be immersion on. Judge some the rowdy you are working and tweet or change it as you are lifting. You present get a lot writer help for your efforts if you rack the ruffian on the steal kinda than retributory raising and movement the unit without focusing on the rowdy. For many entropy and tips on utilize, go to http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 06:56:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 06:56:02 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.ebaec50aee97e057532eafca4016c359@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I can't reproduce the behaviour either, though I am not using precisely 7.8.3. Can other people reproduce? Can you compile both ways with `-dverbose-core2core -ddump-occur-anal -ddump-rule-rewrites -ddump-inlinings` and attach the results? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 07:10:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 07:10:45 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.010d88c269f3b8181115514b92227c4f@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Note to self: however with HEAD (but not with 7.8) I get {{{ WARNING: file compiler/simplCore/SimplCore.lhs, line 629 Simplifier bailing out after 4 iterations [584, 82, 104, 18] Size = {terms: 655, types: 264, coercions: 12} }}} so I'm getting more simplifier iterations apparently. Not related to the issue at hand, though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 10:15:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 10:15:26 -0000 Subject: [GHC] #9375: Support for module thinning/renaming on command line In-Reply-To: <045.7767d06b67f08763343ee12e2c8eb40a@haskell.org> References: <045.7767d06b67f08763343ee12e2c8eb40a@haskell.org> Message-ID: <060.14d7498a38ef5139d7de627be0bc88ef@haskell.org> #9375: Support for module thinning/renaming on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"207875293fea07aa90efe215369629b657d1875a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="207875293fea07aa90efe215369629b657d1875a" Thinning and renaming modules from packages on the command line. Summary: This patch set adds support for extra syntax on -package and related arguments which allow you to thin and rename modules from a package. For example, this argument: -package "base (Data.Bool as Bam, Data.List)" adds two more modules into scope, Bam and Data.List, without adding any of base's other modules to scope. These flags are additive: so, for example, saying: -hide-all-packages -package base -package "base (Data.Bool as Bam)" will provide both the normal bindings for modules in base, as well as the module Bam. There is also a new debug flag -ddump-mod-map which prints the state of the module mapping database. H = hidden, E = exposed (so for example EH says the module in question is exported, but in a hidden package.) Module suggestions have been minorly overhauled to work better with reexports: if you have -package "base (Data.Bool as Bam)" and mispell Bam, GHC will suggest "Did you mean Bam (defined via package flags to be base:Data.Bool)"; and generally you will get more accurate information. Also, fix a bug where we suggest the -package flag when we really need the -package-key flag. NB: The renaming afforded here does *not* affect what wired in symbols GHC generates. (But it does affect implicit prelude!) ToDo: add 'hiding' functionality, to make it easier to support the alternative prelude use-case. ToDo: Cabal support Signed-off-by: Edward Z. Yang Test Plan: new tests and validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D113 GHC Trac Issues: #9375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 10:25:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 10:25:04 -0000 Subject: [GHC] #9375: Support for module thinning/renaming on command line In-Reply-To: <045.7767d06b67f08763343ee12e2c8eb40a@haskell.org> References: <045.7767d06b67f08763343ee12e2c8eb40a@haskell.org> Message-ID: <060.00ffa3955399c4ebfe77121aec7f9c24@haskell.org> #9375: Support for module thinning/renaming on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 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 Tue Aug 5 10:26:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 10:26:11 -0000 Subject: [GHC] #9265: Create PackageKey to replace PackageId, including version dependency information In-Reply-To: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> References: <045.e1e117ee2181d2f7d136b8d6e81cfd5f@haskell.org> Message-ID: <060.00d48b8a0d528234f7d655447f3b1748@haskell.org> #9265: Create PackageKey to replace PackageId, including version dependency information -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.9 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 Comment: We'll leave #9351 as further work in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 12:29:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 12:29:09 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.a0d0c7a3d0464a4683084ac69bc62dfe@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by arotenberg): I have verified that I can consistently recreate the issue on another computer running Windows 7 x86-64 with GHC 7.8.3. I believe the issue was also present in 7.8.2, since I upgraded to 7.8.3 with the express purpose of seeing if this issue had been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 13:53:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 13:53:42 -0000 Subject: [GHC] #9408: Muscle Building Is Easy If You Follow A Constructive Approach Message-ID: <050.2c357390b47cd497ee2ec0e967b946d0@haskell.org> #9408: Muscle Building Is Easy If You Follow A Constructive Approach -------------------------------------+------------------------------------- Reporter: aldofrnak45 | 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: -------------------------------------+------------------------------------- Hooligan edifice is certainly effortless and baccate. It gift wage you a tenacious long bouncing being and you gift be fit to add liveliness in your daily [http://testcorepromuscleuk.com/ Testcore Pro] activities. Sinew antiquity is really near for you gross welfare. Roughneck structure moldiness be followed by any impelling and creative strategies. Swing yourself into a organization faculty not progress your muscles. You hit to use liberal, roughneck business is author competent exclusive when followed by a advantageous attitude and constructive skyway. Let me tell you whatsoever of the benefits of disentangled weights and few harms of hateful tough construction achines.The barbells module enable you to move heavier weights. As a affair of fact the much coefficient you rhytidoplasty, the writer you add mass to muscles. Dumbbells are also a genuine thing of coefficient lifting. The earthy metric lifting techniques are manifestly '''Testcore Pro''' surpass than the machines. The tough antiquity machines beautify a justification of injuries and sinew cramps by forcing you in taped and supernatural oefficient lifting techniques. On the other side, issue weight unbleached way. Emancipated weights gift drop you from overtraining and author vivification module be filled in your muscles. Supply weights enable your body to record a fit and standard. You are fit to teach the science of stability. You poorness not to emotion from insanity. This unprocessed balance module sure bod more roughneck body and you are healthy to increase writer positive. Thence, hooligan business becomes much competent the discharged coefficient model. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 13:54:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 13:54:24 -0000 Subject: [GHC] #9409: Muscle Building Is Easy If You Follow A Constructive Approach Message-ID: <050.b0d223e5705cae3d1f5ef8c3ae08c406@haskell.org> #9409: Muscle Building Is Easy If You Follow A Constructive Approach -------------------------------------+------------------------------------- Reporter: aldofrnak45 | 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: -------------------------------------+------------------------------------- Hooligan edifice is certainly effortless and baccate. It gift wage you a tenacious long bouncing being and you gift be fit to add liveliness in your daily activities. [http://testcorepromuscleuk.com/ Testcore Pro] Sinew antiquity is really near for you gross welfare. Roughneck structure moldiness be followed by any impelling and creative strategies. Swing yourself into a organization faculty not progress your muscles. You hit to use liberal, roughneck business is author competent exclusive when followed by a advantageous attitude and constructive skyway. Let me tell you whatsoever of the benefits of disentangled weights and few harms of hateful tough construction machines.The barbells module enable you to move heavier weights. As a affair of fact the much coefficient you rhytidoplasty, the writer you add mass to '''Testcore Pro''' muscles. Dumbbells are also a genuine thing of coefficient lifting. The earthy metric lifting techniques are manifestly surpass than the machines. The tough antiquity machines beautify a justification of injuries and sinew cramps by forcing you in taped and supernatural coefficient lifting techniques. On the other side, issue weight unbleached way. Emancipated weights gift drop you from overtraining and author vivification module be filled in your muscles. Supply weights enable your body to record a fit and standard. You are fit to teach the science of stability. You poorness not to emotion from insanity. This unprocessed balance module sure bod more roughneck body and you are healthy to increase writer positive. Thence, hooligan business becomes much competent the discharged coefficient model. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 13:55:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 13:55:00 -0000 Subject: [GHC] #9410: Muscle Building Is Easy If You Follow A Constructive Approach Message-ID: <050.36de42620ee441e5d39d8c6e3e04db43@haskell.org> #9410: Muscle Building Is Easy If You Follow A Constructive Approach -------------------------------------+------------------------------------- Reporter: aldofrnak45 | 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: -------------------------------------+------------------------------------- Hooligan edifice is certainly effortless and baccate. It gift wage you a tenacious long bouncing being and you gift be fit to add liveliness in your daily activities.[http://testcorepromuscleuk.com/ Testcore Pro] Sinew antiquity is really near for you gross welfare. Roughneck structure moldiness be followed by any impelling and creative strategies. Swing yourself into a organization faculty not progress your muscles. You hit to use liberal, roughneck business is author competent exclusive when followed by a advantageous attitude and constructive skyway. Let me tell you whatsoever of the benefits of disentangled weights and few harms of hateful tough construction machines.The barbells module enable you to move heavier weights. As a affair of fact the much coefficient you rhytidoplasty, the writer you add mass to muscles. Dumbbells are also a genuine '''Testcore Pro''' thing of coefficient lifting. The earthy metric lifting techniques are manifestly surpass than the machines. The tough antiquity machines beautify a justification of injuries and sinew cramps by forcing you in taped and supernatural coefficient lifting techniques. On the other side, issue weight unbleached way. Emancipated weights gift drop you from overtraining and author vivification module be filled in your muscles. Supply weights enable your body to record a fit and standard. You are fit to teach the science of stability. You poorness not to emotion from insanity. This unprocessed balance module sure bod more roughneck body and you are healthy to increase writer positive. Thence, hooligan business becomes much competent the discharged coefficient model. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 13:55:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 13:55:43 -0000 Subject: [GHC] #9411: Muscle Building Is Easy If You Follow A Constructive Approach Message-ID: <050.ad5adefe84c6ec976153cafe3e126ce5@haskell.org> #9411: Muscle Building Is Easy If You Follow A Constructive Approach -------------------------------------+------------------------------------- Reporter: aldofrnak45 | 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: -------------------------------------+------------------------------------- Hooligan edifice is certainly effortless and baccate. It gift wage you a tenacious long bouncing being and you gift be fit to add liveliness in your daily activities.[http://testcorepromuscleuk.com/ Testcore Pro] Sinew antiquity is really near for you gross welfare. Roughneck structure moldiness be followed by any impelling and creative strategies. Swing yourself into a organization faculty not progress your muscles. You hit to use liberal, roughneck business is author competent exclusive when followed by a advantageous attitude and constructive skyway. Let me tell you whatsoever of the benefits of disentangled weights and few harms of hateful tough construction machines.The barbells module enable you to move heavier weights. As a affair of fact the much coefficient you rhytidoplasty, the writer you add mass to muscles.'''Testcore Pro''' Dumbbells are also a genuine thing of coefficient lifting. The earthy metric lifting techniques are manifestly surpass than the machines. The tough antiquity machines beautify a justification of injuries and sinew cramps by forcing you in taped and supernatural coefficient lifting techniques. On the other side, issue weight unbleached way. Emancipated weights gift drop you from overtraining and author vivification module be filled in your muscles. Supply weights enable your body to record a fit and standard. You are fit to teach the science of stability. You poorness not to emotion from insanity. This unprocessed balance module sure bod more roughneck body and you are healthy to increase writer positive. Thence, hooligan business becomes much competent the discharged coefficient model. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 14:48:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 14:48:10 -0000 Subject: [GHC] #9412: Get Your Body In Fantastic Shape By Following These Fitness Tips Message-ID: <050.574ecc48921434dfabce4aa3a17eab50@haskell.org> #9412: Get Your Body In Fantastic Shape By Following These Fitness Tips -------------------------------------+------------------------------------- Reporter: aldofrnak45 | 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: -------------------------------------+------------------------------------- Condition is not an unproblematic thing to maintain decent, but it is one that rewards you ten-fold for all the impact you put in. Yet, in visit to stay well, [http://testcorepromuscleuk.com/ Testcore Pro] it is really serious. Luckily, it is not needful to bang utmost measures. Righteous a lowercase example and travail on your effort is all that's needed. You could person fun as surface.Involve a burst when your body feels equal it needs one. Few trainers say you should desist resting eliminate after fact exercises or when dynamic from one practise to another. Notwithstanding, your body module let you bed when it needs a trespass many accurately than the trainers leave. When your embody says you beggary to pose, do it! Actuation yourself tense this convexity may prove in an unhealthiness.Cleaning is one way to get some sweat. If you regain yourself descending on the control cleanup up a blob or shed, do both hurtle repetitions. Doing pushups also entirety in this position. If you enlist in brief bursts of utilise whenever you can, you faculty get punt in structure before you cognize it.If you're suffering from a turn in your muscles, it's '''Testcore Pro''' valuable to deal ice to the agonistic atlantic. Ice minimizes puffiness and redness. Also, be reliable that you fix the country that is studied elevated to ensure priggish blood line. Use a rag or towel to place the ice in before putting it on your body.It's central to imbibe irrigate as oftentimes as researchable. You fruit alter through roughneck fibers causation conflict with one added, along with dryness. The excrete glands in your embody destroy the change, which results in minor dehydration.Are you trying to get legs that instrument movement heads? Then it is important that you try both sitting and standing subaltern leg lifts. Since there are two groups of leather yobo, excavation on them in umteen slipway module provide you obtain the superfine results.You do not feature to fair eat complete grains at breakfast. There are umpteen options here and whatever of the healthiest are grain, quinoa and emancipationist dramatist. You can add these type of foods to luncheon and party meals. You'll get that this allows unit grains to easily embellish a start of your fast. http://testcorepromuscleuk.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 15:18:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 15:18:36 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.684080c2c7eda21556331dc682c218c0@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- 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: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: invalid => Comment: Re-opening because I think we should fix GHC as comment:4 etc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 17:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 17:04:34 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled In-Reply-To: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> References: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> Message-ID: <059.9d0de7404033b6b23548405c70a08151@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: pthread staticlib Operating System: MacOS X | threaded Type of failure: Compile- | Architecture: x86 time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D120 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D120 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 17:51:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 17:51:17 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string In-Reply-To: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> References: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> Message-ID: <060.85a19d26dead28b71267077b78d0e2c6@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"d360d440b994c03d645603c50f25ef208700db02/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d360d440b994c03d645603c50f25ef208700db02" Filter out null bytes from trace, and warn accordingly, fixing #9395. Summary: Previously, if you ran trace "foo\0bar", the output was truncated so that everything after the null byte was omitted. This was terrible. Now we filter out null bytes, and emit an extra trace saying that null bytes were filtered out. NB: we CANNOT fix debugBelch, because all printf variants *always* respect null bytes, even if you're using string precision such as %.*s. The alternative would have been to introduce a new function debugRawBelch which did not use format strings and took an explicit string length, but I decided we generally should avoid putting null bytes in our trace messages, and warn the user. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: hvr, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D121 GHC Trac Issues: #9395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 17:52:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 17:52:12 -0000 Subject: [GHC] #9395: Debug.Trace should not use %s for format string In-Reply-To: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> References: <045.d71a807be76b844eb506feb4f2751d4c@haskell.org> Message-ID: <060.a5671a32b1a759f831ef68f59e38c210@haskell.org> #9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 17:57:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 17:57:20 -0000 Subject: [GHC] #9413: Outputable instance for Unique sometimes generates null bytes Message-ID: <045.4dfc81b6be7e6d723b0fdf9d189aff1a@haskell.org> #9413: Outputable instance for Unique sometimes generates null bytes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Steps to reproduce: {{{ [ezyang at hs01 ghc-validate]$ inplace/bin/ghc-stage2 --interactive -package ghc GHCi, version 7.9.20140805: 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 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 unix-2.7.0.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.21.0.0 ... 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.4.1.0 ... linking ... done. Loading package ghc ... linking ... done. Prelude> :m +Unique Prelude Unique> :m +Outputable Prelude Unique Outputable> :m +FastString Prelude Unique Outputable FastString> :m +DynFlags Prelude Unique Outputable FastString DynFlags> showSDoc (defaultDynFlags undefined) $ ppr (getUnique (mkFastString "foo")) "\NUL3bS" }}} We should do something so this doesn't happen. Caused grief due to #9395 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 19:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 19:46:34 -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.9d36b976e6e4f04793e35b78a5846ef0@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): Right. I'm utterly swamped, but happy to advise. I think it would not be hard to fix this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 20:37:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 20:37:48 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.6ae7512cada04a1568a191910a0fb74d@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 simonpj): I think you are right. Try giving `seq` that type, and removing the special case. (There would need to be a Note with the new type of course.) The situation with tcInfer etc is still not cool, but other things being equal simpler is definitely better. Maybe you can try these changes in HEAD, not just on nokinds? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 20:49:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 20:49:24 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.343235d37bafbb423137476a6d66550d@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I have this 95% done, but keep getting distracted. I hope to commit my fix on Thursday. It can go in 7.8.4 if we ever make such a release. Meanwhile, notice that you are in effect using an inlined version of `unsafePerformIO`: your function `inlineWriteB` conjures up a `realWorld#` and then discards it again. If you use the real `unsafePerformIO` (which is not inlined until much later if at all) I think the problem will go away. That might be a workaround. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 20:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 20:51:54 -0000 Subject: [GHC] #9400: poor performance when compiling modules with many Text literals at -O1 In-Reply-To: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> References: <047.cff0491d63e6a0946e85d2106d750190@haskell.org> Message-ID: <062.787172d5e39e24a66ab6dc41deedab4b@haskell.org> #9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- 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: Compile- | Blocked By: time performance bug | Related Tickets: #9370 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Would anyone be willing to try the fix I describe above? I can advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 21:15:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 21:15:22 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.03afad06c0af7ee6bc7efbdd68470299@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci 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): Dear s9gf4ult (I wonder who you are in real life?) That makes sense. For classes, actually `:info Eq` lists all the instances of `Eq`, so maybe that should happen for `type` and `data` families too? Then adding arguments could filter the list to just the instances that match the pattern given? Would you, or anyone else, like to specify the feature and offer a patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 21:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 21:19:01 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.b397f0442cc7d60f6ba6c8f9dc80e8cb@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.6.1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by kim): * cc: simonmar (added) Comment: On OSX 10.0 and ghc 7.8.x I'm seeing the following behaviour: * {{{ threadDelay minBound }}} returns immediately (with or without {{{ -threaded }}}) * {{{ threadDelay maxBound }}} without {{{ -threaded }}}, the program terminates with: {{{ maxbound: select: Invalid Argument }}} (similar to #6019) * {{{ threadDelay maxBound }}} ''with'' {{{ -threaded }}} prints on stderr: {{{ maxbound: c_poll: invalid argument (Invalid argument) maxbound: ioManagerWakeup: write: Bad file descriptor }}} and then appears to hang. When running it on a different thread, which is then killed from the main thread after some time, the following line is printed in after the above: {{{ maxbound: ioManagerWakeup: write: Bad file descriptor }}} The program makes no progress after the thread got killed. Curiously, on another machine with same OS and ghc versions but more cores, the program crashes instead of hangs. (similar to #5544) * as described by the reporter, for some values < {{{ maxBound }}} but in the same order of magnitude, the errors disappear, but for others they don't. Please do let me know if providing {{{ dtruss }}} output would be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 21:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 21:30: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.1770c4acb59b8f93992e00ada6792bb1@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): David, I don't think it's feasible to remove `OVERLAPS` at the moment, unless you can amass some real support for it. * Main reason: people have argued precisely the opposite: that `OVERLAPPING` and `OVERLAPPABLE` are too complicated, and they should be removed in favour of just `OVERLAPS`. In principle I like the idea of forcing people to be explicit, but I think it's bridge too far. * Tiresome reason: the parser isn't up to parsing two pragmas; currently `{-# OVERLAPPING, OVERLAPPABLE #-}` isn't allowed. Someone would have to fix that. Of course, if `-XSafe` is on, you can modify the behaviour if you like. So if you want to propose something along those lines, go ahead. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 21:50:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 21:50:13 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.7126a6a3d65862703e8e3403edfcc37b@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 dterei): I noticed Andreas Abel on the mailing list objected to removing `OVERLAPS` but otherwise felt people were silent on the issue. We don't want to just make a chance in `-XSafe` as ideally `-XSafe` and GHC Haskell are as close as possible, otherwise the long term viability of Safe Haskell isn't good. I'll see what support I can rally or alternatives come up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 22:23:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 22:23:12 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.b0a514ef61d0ed216ec215fa02acff9c@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.6.1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 5 22:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Aug 2014 22:27:48 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.35d3a99107d3383f5a2f7bc92dce4627@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 carter): I'd be willing to do the leg work for augmenting the pragma parser, since I need to get familiar with the pragma parser anyways for some of my own work. (if of course, that would enable a desired design choice, if not that don't mind me) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 03:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 03:30:58 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.bd4b09270a115d441cc267d609ed876a@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): Ah, yes, that makes good sense. Patch will arrive soon. Thanks for the explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 04:35:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 04:35:57 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.72bb8b7ce37e8123a6fa2b6c4225b9af@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by snoyberg): Yes, using `unsafePerformIO` or `unsafeDupablePerformIO` works as expected in my example. However, Carter's example above fails even with `unsafePerformIO`, so something fishy is still going on. And if I apply my patch to the primitive package to work around the issue here, Carter's example no longer gives an incorrect result. So even though the avoidance of inlining in `unsafePerformIO` does work around the simple example I gave above, there are still places where the current behavior can manifest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 05:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 05:18:10 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.227735d09245267e706904bb73741aee@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by carter): On the flip side, the version in my example is also VERY weird code to write also, I can't imagine anything like my example occurring in the wild. Most uses of unsafe*PerformIO in the wild "return" a value thats used by the rest of the program, BUT both mine and snoymans examples are per se "dead code" wrt the alleged purity! I think my example might just simply be legal CSE wrt alleged purity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 07:21:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 07:21:20 -0000 Subject: [GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI Message-ID: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> #9414: GHC 7.8.3 compilation fails on Raspberry PI ----------------------------+--------------------------------------- Reporter: ipuustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------- Tried to compile GHC 7.8.3 from the source package on Raspbian (a Debian- based Raspberry PI distribution). The installed GHC version is 7.4.1. All build dependencies for 7.4.1 were installed ('apt-get build-dep ghc'). {{{ "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll- split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist- install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll- split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user- package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist- install/build -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/filepath/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build' -optl-L'/home/pi/ghc/ghc-7.8.3/rts/dist/build' -optl-lgmp -optl-lm -optl-lrt -optl-ldl -fPIC -dynamic -H32m -O -hide-all- packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist- install/build -Iutils/dll-split/dist-install/build/autogen -optP- include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.1 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -fno-use- rpaths -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/../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.0.1' -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 utils/dll-split /dist-install/build/Main.dyn_o "cp" -p utils/dll-split/dist-install/build/tmp/dll-split inplace/lib/bin /dll-split "rm" -f inplace/bin /dll-split echo '#!/bin/bash' >> inplace/bin/dll-split echo 'executablename="/home/pi/ghc/ghc-7.8.3/inplace/lib/bin/dll-split"' >> inplace/bin/dll-split echo 'datadir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'bindir="/home/pi/ghc/ghc-7.8.3/inplace/bin"' >> inplace/bin/dll-split echo 'topdir="/home/pi/ghc/ghc-7.8.3/inplace/lib"' >> inplace/bin/dll-split echo 'pgmgcc="/usr/bin/gcc"' >> inplace/bin/dll-split echo 'export LD_LIBRARY_PATH="/home/pi/ghc/ghc-7.8.3/libraries/filepath /dist-install/build:/home/pi/ghc/ghc-7.8.3/libraries/containers/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/deepseq/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/array/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/base/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/integer-gmp/dist- install/build:/home/pi/ghc/ghc-7.8.3/libraries/ghc-prim/dist- install/build:/home/pi/ghc/ghc-7.8.3/rts/dist/build:$LD_LIBRARY_PATH"' >> inplace/bin/dll-split echo 'exec "$executablename" ${1+"$@"}' >> inplace/bin /dll-split chmod +x inplace/bin /dll-split inplace/bin/dll-split compiler/stage2/build/.depend-v-p-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 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] Keskeytetty make: *** [all] Virhe 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 08:49:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 08:49:29 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.81718016fa6b1b0e3fe8cc34abd49ec4@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci 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 s9gf4ult): Hello, Simon! Unfortunately, I have no experience with GHC code base to make a patch. What do you mean about "to specify the feature" ? My English is not native... In real life I am like a https://github.com/s9gf4ult (dont have good personal blog) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 09:49:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 09:49:49 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.4e9d34a33c7387fdab63049de1a30594@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): The example in comment:2 is different in kind to the main one. Considre {{{ (unsafePerformIO (do { write arr 0 'A'; return 3 }) + (unsafePerformIO (do { write arr 0 'B'; return 4 }) }}} After you evaluate this, does `arr[0]` contain `'A'` or `'B'`? Obviously it depends on the evaluation order of `(+)`. GHC is, quite specifically, at liberty to change evaluation order -- notably the strictness analyser makes quite radical changes in evaluation order -- so you absolutely cannot rely on it. Even if you say {{{ a `seq` b `seq` d }}} you cannot rely on `a` being evaluated before `b`. In short: * GHC is tries never to ''discard'' exceptions, divergence, or write effects * but it is free to ''re-order'' them (See our paper "A semantics for imprecise exceptions" for lots of detail on this.) The only way to enforce sequencing of write effects is to us the data dependency of the state token. By using `unsafePerformIO` you are specifically saying "I don't mind in what order these effects are performed relative to everything else. `unsafeInterleaveIO` lets you ensure that it occurs after the effects thus far in the do-block have occurred. So this: {{{ main = do vm <- VM.new 1 VM.write vm 0 'A' !b<- return $! 'B' x <- unsafeInterleaveIO $! VM.write vm 0 b x `seq` (V.freeze vm >>= print) }}} always prints "B". These things are not obvious. We have a good place for "collaborative documentation" of GHC, [http://www.haskell.org/haskellwiki/GHC here]. Would any of you like to write an explanatory page there? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 09:55:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 09:55:21 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.e598abc604939df0d0dcc54a95c1a077@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by snoyberg): I'm confused about the end of your comment, in particular: > `unsafeInterleaveIO` lets you ensure that it occurs after the effects thus far in the do-block have occurred But your example then implies that the `x` thunk will reliably be evaluated before `V.freeze vm >>= print`, which does not seem to follow from your comment. Can you clarify? I'd be happy to take a crack at writing up some documentation. For a while, I've wanted to have a clear set of rules for when `unsafePerformIO`, `unsafeDupablePerformIO`, and `inlinePerformIO` (aka unsafeAccursedPerformIO) are safe to use. Once I get some more clarity from our discussion here, I'd like to take a pass at such a Wiki page, and would greatly appreciate your review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 10:11:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 10:11:57 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.7dfd531f9e9757d0011d266a59602fcd@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): My comment meant that the `x` thunk will reliably be evaluated only after performing the `write A` side effect. The question of whether it is performed before the freeze is quite a separate one. Yes it will, because the `seq` ensures that (in effect) there is a data dependency between `x` and `(V.freeze vm >>= print)`, so we can't perform the latter action until we have evaluated `x`. If instead of {{{x `seq` (V.freeze vm >> print)}}} we'd written {{{ if x>0 then V.freeze vm >> print else print "hello" }}} it would be totally clear that you couldn't do the freeze until `x` was evaluated. And `seq` behaves like that. Does that make it clearer? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 10:39:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 10:39:49 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.74fcaf2f8716b89ae42fc3a6cecd12ab@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by snoyberg): I think so, let me see if I've got a grasp of this. In Carter's example above, there are essentially the following steps: 1. Create a new vector. 2. Write 'A' into the vector. 3. Write 'B' into the vector. 4. Freeze and print the vector. The ordering dependencies in the code are as follows: * Steps 2, 3, and 4 all depend on step 1 occurring. * Step 4 depends on step 2 (due to ordering in the IO monad) and step 3 (due to the usage of seq). However, there is no clearly expressed ordering between 2 and 3. Even those we only force evaluation of step 3's thunk "after" step 2 is performed, there is nothing in the code to express this as a strict ordering requirement, and therefore GHC is at full liberty to perform step 3 before step 2. In your code, however, by using `unsafeInterleaveIO`, we have in fact stated a strict ordering requirement that step 3 occur after step 2, which solves the problem. And none of this has anything to do with my original example, which has to do with some primops being optimized away depending on how their resulting `State#` is handled (whether inside a `case` or not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 11:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 11:53:29 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.8ac07d98049ba000fe434641400096a3@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Correct. And I edited comments:12, where I had previously said something wrong. I should also add that {{{(a `pseq` blah)}}} '''does''' guarantee that `a` is evaluated before the evaluation of `blah` is begun. That's the difference between `seq` and `pseq`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 12:04:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 12:04:03 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.4523b09ff0f670c4e7bece4b1a93053d@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by snoyberg): I think you were implying this, but just for complete clarity (and since I'd want to include it in an explanatory document), when we have: {{{ x `seq` (y :: IO a) }}} We have no control of whether `x` or `y` will be evaluated first, and therefore there is no ordering of side effects from the evaluation of `x` and `y`. However, the IO action contained by `y` *will* be guaranteed to be run after both `x` and `y` are evaluated. In other words, with the code: {{{ let x = unsafePerformIO $ putStrLn "x evaluated" y = unsafePerformIO $ do putStrLn "y evaluated" return $ "y run" x `seq` y }} The ordering of "x evaluated" and "y evaluated" is undefined, but we are guaranteed that both of them will be print before "y run". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 13:03:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 13:03:28 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.47f0c2c180d491b7872e42ca380b66c5@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by arotenberg): I have now also verified that this problem does ''not'' occur on 32-bit Windows nor when using 32-bit GHC on 64-bit Windows. But you should be able to reproduce it if you use 64-bit Windows and 64-bit GHC 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 13:38:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 13:38:23 -0000 Subject: [GHC] #9415: Superclass cycle with ambiguous type causes loop Message-ID: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> #9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- If I say {{{ class D a => C a where meth :: D a => () class C a => D a }}} I get a loop in the typechecker. I know what's going on here: the error for the superclass cycle is added during the validity check, but then we go on to do ambiguity checks. Unfortunately, the ambiguity check never finishes. We just need to bail when there are superclass errors before doing the ambiguity check. Patch on the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 14:50:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 14:50:22 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) Message-ID: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Found by ./validate: '''testsuite/tests/rts/overflow1.hs''' SIGSEGVs due to integer overflow somewhere around [https://git.haskell.org/ghc.git/blob/c88559b3304cc5e142ab9c2655d48e570f81afeb:/compiler/codeGen/StgCmmPrim.hs#l138 shouldInlinePrimOp] {{{#!hs ... shouldInlinePrimOp dflags NewByteArrayOp_Char [(CmmLit (CmmInt n _))] | fromInteger n <= maxInlineAllocSize dflags = ... }}} '''maxInlineAllocSize''' has ''':: Int''' type: {{{#!hs fromInteger (2^64 - 10) < (128 :: Int) True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 14:59:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 14:59:26 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock Message-ID: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Create modules as follows {{{#!hs -- PatSymDef.hs {-# Language PatternSynonyms #-} module PatSymDef where pattern Some a = Just a }}} {{{#!hs -- PatSymUse.hs {-# Language PatternSynonyms #-} module PatSymUse where import PatSymDef f :: Maybe Int -> Int f (Some a) = a f Nothing = 0 }}} Then run Haddock against them: {{{ [nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp Haddock coverage: Warning: Not found in environment: Some 50% ( 1 / 2) in 'PatSymDef' /tmp/PatSymUse.hs:9:4: Can't find interface-file declaration for data constructor Some Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the pattern: Some a In an equation for ?f?: f (Some a) = a }}} Here with -ddump-if-trace: {{{ [nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp --optghc='-ddump-if-trace' Haddock coverage: Considering whether to load base:Prelude Reading interface for base:Prelude; reason: Prelude is directly imported readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.dyn_hi updating EPS_ updating EPS_ Considering whether to load base:GHC.Base {- SYSTEM -} Reading interface for base:GHC.Base; reason: Loading orphan modules (base:GHC.Base) readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.dyn_hi updating EPS_ Considering whether to load base:GHC.Float {- SYSTEM -} Reading interface for base:GHC.Float; reason: Loading orphan modules (base:GHC.Float) readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.dyn_hi updating EPS_ Considering whether to load base:GHC.Real {- SYSTEM -} Reading interface for base:GHC.Real; reason: Loading orphan modules (base:GHC.Real) readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.dyn_hi updating EPS_ loadHiBootInterface main at main:PatSymDef Considering whether to load base:Data.Maybe {- SYSTEM -} Reading interface for base:Data.Maybe; reason: The name ?Data.Maybe.Just? is mentioned explicitly readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.dyn_hi updating EPS_ Starting fork { Declaration for Maybe Loading decl for Data.Maybe.Maybe updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} Reading interface for ghc-prim:GHC.Prim; reason: Need home interface for wired-in thing * updating EPS_ Start interface-file tc_con_decl Nothing Done interface-file tc_con_decl Data.Maybe.Nothing Start interface-file tc_con_decl Just Done interface-file tc_con_decl Data.Maybe.Just tcIfaceDecl4 Data.Maybe.Maybe } ending fork Declaration for Maybe Starting fork { Constructor Data.Maybe.Nothing } ending fork Constructor Data.Maybe.Nothing Starting fork { Constructor Data.Maybe.Just } ending fork Constructor Data.Maybe.Just ==================== Interface statistics ==================== Renamer stats: 6 interfaces read 1 type/class/variable imported, out of 776 read 0 instance decls imported, out of 42 read 0 rule decls imported, out of 53 read Need decl for PatSymDef.Some Considering whether to load main at main:PatSymDef {- SYSTEM -} Warning: Not found in environment: Some 50% ( 1 / 2) in 'PatSymDef' Considering whether to load base:Prelude Considering whether to load main at main:PatSymDef updating EPS_ Considering whether to load base:GHC.Base {- SYSTEM -} Considering whether to load base:GHC.Float {- SYSTEM -} Considering whether to load base:GHC.Real {- SYSTEM -} loadHiBootInterface main at main:PatSymUse Considering whether to load base:Data.Maybe {- SYSTEM -} Considering whether to load ghc-prim:GHC.Types {- SYSTEM -} Reading interface for ghc-prim:GHC.Types; reason: The name ?GHC.Types.Int? is mentioned explicitly readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.hi readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg- ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.dyn_hi updating EPS_ Considering whether to load ghc-prim:GHC.Types {- SYSTEM -} Considering whether to load main at main:PatSymDef {- SYSTEM -} Considering whether to load base:Data.Maybe {- SYSTEM -} Considering whether to load ghc-prim:GHC.Types {- SYSTEM -} Considering whether to load ghc-prim:GHC.Types {- SYSTEM -} Need decl for PatSymDef.Some Considering whether to load main at main:PatSymDef {- SYSTEM -} /tmp/PatSymUse.hs:9:4: Can't find interface-file declaration for data constructor Some Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the pattern: Some a In an equation for ?f?: f (Some a) = a }}} Originally reported to me against Haddock 2.14.3, GHC 7.8.3 and I can confirm both there and on yesterday's GHC HEAD. It'd be great if whoever is involved with pattern synonyms could take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 15:03:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 15:03:23 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.ba3e4c5d22aeb2003fe2195efa0e810b@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by slyfox): * owner: => tibbe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 15:23:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 15:23:39 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.66126d9d17b0dc47090f8a418f26cc26@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: gadt/type- | rep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): On './validate --slow' TEST="type-rep" also passes for me in -HEAD: {{{ Unexpected results from: TEST="type-rep }}} Does it make sense to reactivate it for '''compiler_debugged()''' case or some yet unfixed subtlety remains in ghc? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 6 20:31:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Aug 2014 20:31:12 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.44e6eb00682abb420a30cf2bac8933e1@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: gadt/type- | rep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the heads up, changed the status of the bug in changeset:f4904fb/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 02:16:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 02:16:34 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.cfe99ee2fb78d834156b93b572f1d984@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Hi folks, I'm trying to use this to get ARM64 compilation working for iOS and am running into this: {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing- declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist- derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc- Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DNOSMP -optc- DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -optc-w -static -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -optc-DNOSMP -dcmm- lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgCRun.c -o rts/dist/build/StgCRun.o rts/StgCRun.c:789:24: error: index must be an integer in range [-256, 255]. STG_RETURN ":\n\t" ^ :13:16: note: instantiated into assembly here ldr lr, [sp], #16384 ^ 1 error generated. }}} (I made a couple of other changes, changing bx to br and references to ip0 and ip1 to x16 and x17, to get things this far) Does that make sense to anyone? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 02:19:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 02:19:23 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.087ddef3a248c45ec0f9ab38ec2d3ae4@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): This is with LLVM HEAD, via {{{brew install llvm --all-targets --with- clang --HEAD}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 02:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 02:48:25 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.b6e267f9e4e40f7259cf4af653cac183@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): LLVM HEAD IS BUSTED with CURRENT GHC HEAD and ALL GHC RELEASES fyi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 02:49:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 02:49:18 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.77e1970ea2fb4b159f486b297a9c0fb8@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): llvm 3.4 should be kosher currently. Ben Gamari started some work on updated llvm bits, but thats not done yet -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 05:25:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 05:25:57 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.b14899c5c8a4b274dc879e89b51961d1@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Yep, I'm using Ben's branch to get LLVM HEAD working in general. I can get a build to complete just fine if I mangle the ASM in StgCRun.c but haven't made it actually work yet. I'm not sure that 3.4 has full ARM64 support (i.e. works on iOS)... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 07:55:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 07:55:56 -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.a561d393a8ea07a8e4e7c85264a0731a@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: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 8364, 9304 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jrp): * cc: jrp (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:21:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:21:40 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.251c5af7142f72b4c337c1319efb7a07@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): OK so it seems likely to be something to do with 64-bit floating-point arithmetic. I wonder if it makes a difference whether you use the native code generator or LLVM? Does anyone feel able to investigate? The program isn't very big, and has no dependencies other than `Prelude`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:34:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:34:55 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.2e4574c5ef39dbb1ef5b321046a58e53@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): OK, so if I replace the offending call with {{{ "ldr lr, [sp]\n\t" "add sp, sp, %3\n\t" }}} (which I believe should be functionally equivalent) I can compile, but then get a crash running on the device here: {{{ HelloHaskell`StgRun: 0x1004cea34: stp x28, x27, [sp, #-96]! 0x1004cea38: stp x26, x25, [sp, #16] 0x1004cea3c: stp x24, x23, [sp, #32] 0x1004cea40: stp x22, x21, [sp, #48] 0x1004cea44: stp x20, x19, [sp, #64] 0x1004cea48: stp fp, lr, [sp, #80] 0x1004cea4c: stp x19, x20, [sp, #-16]! 0x1004cea50: stp x21, x22, [sp, #-16]! 0x1004cea54: stp x23, x24, [sp, #-16]! 0x1004cea58: stp x25, x26, [sp, #-16]! 0x1004cea5c: stp x27, x28, [sp, #-16]! 0x1004cea60: stp x16, x17, [sp, #-16]! 0x1004cea64: str lr, [sp, #-8]! 0x1004cea68: str lr, [sp, #16384] <------------EXC_BAD_ACCESS (code=259, address=0x16fdcf7a8) 0x1004cea6c: mov x19, x1 0x1004cea70: br x0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:39:19 -0000 Subject: [GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker" Message-ID: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> #9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Gabor rightly complains: I see literally ''thousands'' of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} }}} This is clearly unsatisfactory, because it is unsettling, and perhaps conceals more important warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:43:56 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.82b5613cad5dca2662039269542f2a7e@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): So basically you try to cross-compile using registerised GHC? If so, then I'm afraid nobody hacked LLVM to support GHC specific calling convention on ARM64 yet! If unregisterised, then you IMHO you should not be in this part of code which is IMHO just for registerised builds. Also if you attempt unregisterised, I would advice to use gcc and not llvm i.e. -fvia-C and not -fllvm for the start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:49:03 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.763e0d044f758a9693ac4bd4d0237cc1@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Ah, that's it! I was wondering if that was done yet. OK, we better get on that then : D Thanks so much for getting this started! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:51:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:51:06 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.9cded3eb32d1e914075d59556253349d@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): One general note: the code in StgCRun written for ARM64 was probably written by me (I've provided the patch to Colin). So if this is this code, then please be assured that this code *never* has run on ARM64. It was written just from reading doc and as a first attempt to add support for registerised ARM64. At that time I've finished with this since I had not machine, ARM's foundation model was really slow and LLVM project was just before big merge from ARM's own AArch64 and Apple's own ARM64 LLVM backends together. Although the situation now looks way much better, at least both LLVM backends were merged together and even some hardware appears this all still means that if nobody has done it yet, then someone needs to do quite a lot. When I've been working on ARM port with Stephen, David helped me a lot and we wrote following LLVM/porting guide. I would recommend to read it: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:53:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:53:39 -0000 Subject: [GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker" In-Reply-To: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> References: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> Message-ID: <061.f9e39d68fd2d2547f4e666451abaea27@haskell.org> #9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- 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): What is happening is this. Consider {{{ class C a where op1 :: a -> a -> (a,a) op2 :: a -> a -> (a,a) {-# INLINE op2 #-} op2 x y = op1 y x instance C Int where op1 x y = (x,y) }}} The intent of the INLINE pragma is obviously to ensure that in every instance declaration we get an INLINEd definition for op2. These declarations desugar to something like this: {{{ op1 :: forall a. C a => a -> a -> (a,a,) op1 c = case c of MkC op1 op2 -> op1 Rec { $dCInt :: C Int = MkC $cop1 $cop2 $cop1 :: Int->Int->(Int,Int) = \xy. (x,y) $cop2 :: Int->Int->(Int,Int) {-# INLINE #-} = \xy -> op1 $dCInt y x } }}} Here * `op1` is the method selector, which picks the `op1` field out of a `C` dictionary. * `$dCInt` is the dictionary for `C Int`. * `$cop1` and `$cop2` are the implementations of `op1` and `op2` at type `Int`. Notice that `$dCInt` and `$cop2` are apparently mutually recursive; each uses the other. We break the mutual recursion by inlining the `op1` selector and `$dCInt` (in the rhs of `$cop2`) so that now we can do the record selection. But do to this, we must inline `$dCInt`, so it can't be a loop breaker. So `$cop2` must be picked as the loop breaker, ''even though it has an INLINE pragma''. That's fine, and it's what GHC does. But Lint is just warning that, as a result, the INLINE pragma isn't going to do anything. This might be useful to the programmer. If you wrote {{{ f x = ....(f y).... {-# INLINE f #-} }}} then `f` won't be inlnined (despite the pragma) because it's recursive. So you might want to re-think your definitions. The Lint warning is just that: a warning. The unravelling of the mutual recursion happens early, otherwise the warning would be repeated after in every subsequent run of the simplifier. So one possible fix would be to have a flag for Core Lint to control whether the warning was enabled, and only switch it on later in the pipeline. But that doesn't seem very satisfactory. Well then. That's why it is the way it is. I'd like it to be better! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:55:22 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.0dcf8f91043e238113e393a0f33965e7@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1fc60ea1f1fd89b90c2992d060aecb5b5a65f8c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1fc60ea1f1fd89b90c2992d060aecb5b5a65f8c0" When desugaring Use the smart mkCoreConApps and friends This is actually the bug that triggered Trac #9390. We had an unboxed tuple (# writeArray# ..., () #), and that writeArray# argument isn't ok-for-speculation, so disobeys the invariant. The desugaring of unboxed tuples was to blame; the fix is easy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 08:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 08:55:22 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.29c285375776a6c70f608ebcb18063e0@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ab6480b8d8ea45ae6958558245266153df071aa5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ab6480b8d8ea45ae6958558245266153df071aa5" Extensive Notes on can_fail and has_side_effects In fixing Trac #9390 I discovered that I *still* didn't really understand what the can_fail and has_side_effects properties of a PrimOp mean, precisely. The big new things I learned are * has_side_effects needs to be true only of *write* effects, Reads (which are, strictly speaking, effects) don't matter here. * has_side_effects must be true of primops that can throw a synchronous Haskell exception (eg raiseIO#) * can_fail is true only of primops that can cause an *unchecked* (not Haskell) system exception, like divide by zero, or accessing memory out of range through an array read or write. I've documented all this now. The changes in this patch are only in comments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 09:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 09:08:13 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.bde3d40c07c02fe8c89b8e6dd6ec9f4a@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2990e97f008c9703eb4b47e24a29d052d5735f00/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2990e97f008c9703eb4b47e24a29d052d5735f00" Test Trac #9390 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 09:08:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 09:08:59 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.72012e8539979a8474d54f4895528af2@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T9390 Comment: If we ever release 7.8.4, the patch in comment:16 should go in. I'm just leaving this open pending Michael's explanatory document Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 09:09:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 09:09:46 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.c783412d83175f5bb74b54ff3f4d8ea0@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Actually I'll change it to 'merge' status lest we forget to merge it one day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 09:13:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 09:13:31 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.5a548edc560949a8f18d5e2bb426c3e0@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Hi Karel, That's really helpful ? well it's run on ARM64 /now/ : D If you (and Stephen, David and Manuel) are up for it I'd love to work on it. Maxwell Swadling, who helped Stephen and I finish up GHC iOS, is in too. I'll read through that doc, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 09:48:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 09:48:04 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.7818ccba8edd45a48b6c33dad5701297@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci 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): OK great. Let's leave this open as a useful feature request. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 10:16:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 10:16:35 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.8b42a224337c94b140eb2c83486b3f72@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by tibbe): I'm working on it. Turns out that trying to fix this exposes all of ours sins i.e. all the places where we use `Int` where we should have used `Word`, for example in `wordsToBytes` and perhaps `ByteOff`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 10:35:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 10:35:16 -0000 Subject: [GHC] #9419: Machine-readable output for profiling Message-ID: <045.c33cc526d01d257d78b4361ea5864f8e@haskell.org> #9419: Machine-readable output for profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- We'll control whether or not machine-readable output is used using the `--machine-readable` flag currently used for GC stats. The format should also be self-explanatory for cost-center stats: per cost center we output the a CSV of `cc->time_ticks`, `cc->mem_alloc`. I'm a little less sure how to format the hierarchical cost center stacks; we could print out the entire trace of the stack, or maybe even organize the data recursively from the get go (outputting something JSON like, in that case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 11:57:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 11:57:50 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.12e26709e93a9d47c9e1be372109963b@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci 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 rodlogic): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 13:09:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 13:09:54 -0000 Subject: [GHC] #9413: Outputable instance for Unique sometimes generates null bytes In-Reply-To: <045.4dfc81b6be7e6d723b0fdf9d189aff1a@haskell.org> References: <045.4dfc81b6be7e6d723b0fdf9d189aff1a@haskell.org> Message-ID: <060.d5ea397f5d61c25fe96de4563a97fce3@haskell.org> #9413: Outputable instance for Unique sometimes generates null bytes -------------------------------------+------------------------------------- Reporter: ezyang | 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: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"4855be0d0d1ac90f836a6fb54f4034f478e38fd8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4855be0d0d1ac90f836a6fb54f4034f478e38fd8" Give the Unique generated by strings a tag '$', fixes #9413. Summary: Previously, we allocated uniques for strings starting at zero, which means the tag bits in the unique are zero, which means that printing a Unique for a string will start with a null byte. This is bad. So instead, start our numbering with the tag byte as '$' (as in $tring). This is hard coded so we don't have to worry about the optimizer reducing the expression. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: hvr, simonmar, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D123 GHC Trac Issues: #9413 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 13:15:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 13:15:31 -0000 Subject: [GHC] #9413: Outputable instance for Unique sometimes generates null bytes In-Reply-To: <045.4dfc81b6be7e6d723b0fdf9d189aff1a@haskell.org> References: <045.4dfc81b6be7e6d723b0fdf9d189aff1a@haskell.org> Message-ID: <060.435996f99dbc0ff83bc149d2fd1070a5@haskell.org> #9413: Outputable instance for Unique sometimes generates null bytes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | 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 ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 13:50:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 13:50:31 -0000 Subject: [GHC] #9419: Machine-readable output for profiling In-Reply-To: <045.c33cc526d01d257d78b4361ea5864f8e@haskell.org> References: <045.c33cc526d01d257d78b4361ea5864f8e@haskell.org> Message-ID: <060.b2e333e850e1806be0148d76efd06685@haskell.org> #9419: Machine-readable output for profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Profiling | 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: D124 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => D124 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 13:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 13:50:45 -0000 Subject: [GHC] #9419: Machine-readable output for profiling In-Reply-To: <045.c33cc526d01d257d78b4361ea5864f8e@haskell.org> References: <045.c33cc526d01d257d78b4361ea5864f8e@haskell.org> Message-ID: <060.f021da7a977ec4c8dc840e99a00e7ca7@haskell.org> #9419: Machine-readable output for profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Profiling | 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/D124| -------------------------------------+------------------------------------- Changes (by ezyang): * differential: D124 => https://phabricator.haskell.org/D124 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 14:47:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 14:47:39 -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.cd63fe5be29fc6e7b3210ed98f1a10e5@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: | -------------------------------------+------------------------------------- Comment (by simonmar): Isn't this fixed now? https://phabricator.haskell.org/D99 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 14:51:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 14:51:44 -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.f080ce7e07147258fd49aeffcfd62840@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: | -------------------------------------+------------------------------------- Comment (by edsko): Termination of the I/O manager is still broken in the general case; Andreas has been working on that and he sent me a patch a few days ago but I haven't had a chance to look at it it -- but the problem is that we will wait indefinitely for the I/O manager to terminate whenever we do a "safe" exit from the RTS (call to `hs_exit` rather than `hs_exit_`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 14:55:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 14:55:57 -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.6c4711eac6423a4b103365bf7dc173e4@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: | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): The issue was that `forkProcess` calls `hs_exit_(rtsTrue)`, which waits for foreign calls to return. Then, the foreign calls made by IO manager threads were not woken up (the cause of this is a bit complicated so I'll explain that elsewhere). The solution in the case of forkProcess is to call `hs_exit(rtsFalse)` which is what normal exit of the Haskell RTS does anyway. However, some clients (e.g. when writing a C program that start and exit GHC RTS) may call `hs_exit()`, which calls `hs_exit_(rtsTrue)`, so the problem of waking up the foreign calls made by IO manager threads remains an issue. I now have a fix for this issue as well. So now the question is: should we close this issue, since it is specific to `forkProcess` and create a separate issue for programs calling `hs_exit()`? Or should we solve both of these issues in this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 15:49:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 15:49: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.dec25ef3106031152d00ffb6c06a9843@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): The Cmm code is fine. As far as I can tell, the .ll file is mostly fine except we do write to a memory location (the original Sp - 4) using TBAA metadata 1 and then later read from the same memory location (and LLVM knows it) using TBAA metadata 5. I lost my disassembly of the object file but it is wrong in a similar way to the assembly I annotated above: LLVM coalesces this store and read to a register move, presumably because it thinks for some reason that the intervening function call can not modify the memory. I don't see why it would assume this, but then again we did tell it via TBAA that two memory accesses would not alias that are in fact to the same address, so I suppose it is within its rights to do anything. amurrayc, can you try with this patch applied (effectively reverting e10589a505b44f4f0394500c6a0d2db5baa7f3f4): {{{ diff --git a/compiler/llvmGen/LlvmCodeGen/Regs.hs b/compiler/llvmGen/LlvmCodeGen/Regs.hs index 0048659..d837d13 100644 --- a/compiler/llvmGen/LlvmCodeGen/Regs.hs +++ b/compiler/llvmGen/LlvmCodeGen/Regs.hs @@ -101,11 +101,6 @@ stgTBAA , (heapN, fsLit "heap", Just topN) , (rxN, fsLit "rx", Just heapN) , (baseN, fsLit "base", Just topN) - -- FIX: Not 100% sure about 'others' place. Might need to be under 'heap'. - -- OR I think the big thing is Sp is never aliased, so might want - -- to change the hieracy to have Sp on its own branch that is never - -- aliased (e.g never use top as a TBAA node). - , (otherN, fsLit "other", Just topN) ] -- | Id values @@ -115,7 +110,7 @@ stackN = getUnique (fsLit "LlvmCodeGen.Regs.stackN") heapN = getUnique (fsLit "LlvmCodeGen.Regs.heapN") rxN = getUnique (fsLit "LlvmCodeGen.Regs.rxN") baseN = getUnique (fsLit "LlvmCodeGen.Regs.baseN") -otherN = getUnique (fsLit "LlvmCodeGen.Regs.otherN") +otherN = topN -- | The TBAA metadata identifier tbaa :: LMString }}} If you can try a newer version of LLVM like 3.4, that would be great also. That version is newer than the admonitions to use 3.0 on the wiki page, so it's possible the LLVM bugs have been worked out in 3.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 15:54:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 15:54:41 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.0e7d924c61be3c7ea713f0ea950f26e0@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: | Owner: BjornEdstrom | 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: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 17:55:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 17:55:28 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.f4765743215e397ce44675a3d89ca2d6@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 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by aavogt): * cc: vogt.adam@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 20:12:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 20:12:01 -0000 Subject: [GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes Message-ID: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> #9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE RankNTypes #-} module Bug where rank2 :: ((forall a. a -> a) -> b) -> () rank2 _ = () foo :: () -> () foo x = x quux :: (forall a. a -> a) -> Int quux _ = 5 bar = foo . rank2 $ quux }}} The `(.)` in the definition of `bar` requires an impredicative instantiation -- that is, one of its type variables is instantiated to a forall-type. Yet, the module compiles without `-XImpredicativeTypes`. To confirm this behavior, the following is an excerpt from `-ddump-simpl`: {{{ Bug.bar = break<7>() (break<6>() GHC.Base.. @ () @ () @ ((forall a_a1Tj. a_a1Tj -> a_a1Tj) -> GHC.Types.Int) Bug.foo (Bug.rank2 @ GHC.Types.Int)) Bug.quux }}} Note the third type argument to `(.)`. Fixing this would be a breaking change that could affect users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 20:36:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 20:36:41 -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.c7d1ca4899f8bbdbb838dace07379eba@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): Capturing work in progress. I've pushed a second iteration to branch `wip/new-flatten-skolems-Aug14`. Still not really right. An interesting case is `indexed-types/should_compile/T3826`; see commments in the source file. Below are my notes {{{ ToDo: * TcInteract, Note [Efficient orientation]? * inert_funeqs, inert_eqs: keep only the CtEvidence. They are all CFunEqCans, CTyEqCans * Update Note [Preparing inert set for implications] * indexed_types/should_compile/T3826 The new flattening story ~~~~~~~~~~~~~~~~~~~~~~~~ * A "flatten-skolem", fsk, is a *unification* variable (ie with an IORef inside it) * A CFunEqCan is always of form [W] x : F xis ~ fsk where x is the witness variable fsk is a flatten skolem xis are function-free CFunEqCans are always [Wanted], never [Given] or [Derived] * Inert set invariant: if [W] F xis1 ~ fsk1, [W] F xis2 ~ fsk2 then xis1 /= xis2 i.e. at most one CFunEqCan with a particular LHS * Each canonical CFunEqCan [W] x : F xis ~ fsk has its own distinct evidence variable x and flatten-skolem fsk. * CFunEqCans are the *only* way that function applications appear in canonical constraints. Function applications in any other constraint must be gotten rid of by flattening, thereby generating fresh CFunEqCans. * Flattening a type (F xis): - Make a new [W] x : F xis ~ fsk with fresh evidence variable x and flatten-skolem fsk - Add it to the work list - Replace (F xis) with fsk in the type you are flattening - You can also add the CFunEqCan to the "flat cache", which simply keeps track of all the function applications you have flattened. If (F xis) is in the cache already, just use its fsk and evidence x, and emit nothing. - No need to substitute in the flat-cache. It's not the end of the world if we start with, say (F alpha ~ fsk1) and (F Int ~ fsk2) and then find alpha := Int. Athat will simply give rise to fsk1 := fsk2 via [Interacting rule] below * Canonicalising ([W} x : F xis ~ fsk) - Flatten xis cos :: xis ~ flat_xis - New wanted x2 :: F flat_xis ~ fsk - Add new wanted to flat cache - Discharge x = F cos ; x2 * Flatten-skolems ONLY get unified when either a) The CFunEqCan takes a step, using an axiom b) During un-flattening at the very, very end They are never unified in any other form of equality. For example [W] fsk ~ Int is stuck; it does not unify with fsk. * We *never* substitute in the RHS (i.e. the fsk) of a CFunEqCan. That would destroy the invariant about the shape of a CFunEqCan, and it would risk wanted/wanted interactions. The only way we learn information about fsk is when the CFunEqCan takes a step. However we *do* substitute in the LHS of a CFunEqCan (else it would never get to fire!) * KEY INSIGHTS: - A flatten-skolem stands for the as-yet-unknown type to which (F xis) will eventually reduce - Although the CFunEqCan is a Wanted, it will almost always eventually be solved, eitehr * [Interacting rule] (inert) x1 : F tys ~ fsk1 (work item) x2 : F tys ~ fsk2 Just solve one from the other: x2 := x1 fsk2 := fsk1 [G] fsk2 ~ fsk1 This just unites the two fsks into one. * [Firing rule] (work item) x : F tys ~ fsk instantiate axiom: co : F tys ~ rhs First flatten rhs, giving flat_co : rhs ~ xi Now unify fsk := xi [G] : fsk ~ xi x := co ; flat_co discharging the work item UNLESS fsk appears in xi, which can happen, in which case don't unnify but stick [W] fsk ~ xi in the insoluble set. --------------- ---------------- Preparing the inert set for implications type instance F True a b = a type instance F False a b = b [W] x : F c a b ~ fsk [G] gamma ~ fsk (c ~ True) => a ~ gamma (c ~ False) => b ~ gamma --> (c ~ True branch) Push in as given non-canonical [G] g : (c ~ True) [G] x : F c a b ~ fsk (nc) [W] a ~ fsk, --> flatten [G] g : (c ~ True) [G] sym x1 ; x : fsk1 ~ fsk [W] x1 : F c a b ~ fsk1 (canon) [W] a ~ fsk, ---> subst c [G] g : (c ~ True) [G] sym x1 ; x : fsk1 ~ fsk [W] x2 : F True a b ~ fsk1 (canon) x1 = F g a b ; x2 [W] a ~ fsk, ---> step ax : F True a b ~ a [G] g : (c ~ True) [G] sym x1 ; x : fsk1 ~ fsk [W] x2 : F True a b ~ fsk1 (canon) [G] : fsk1 := a x2 = ax [W] a ~ fsk, -------------------------- Simple20 ~~~~~~~~ axiom F [a] = [F a] [G] F [a] ~ a --> [G] fsk ~ a [W] F [a] ~ fsk --> fsk := [fsk2] [G] [fsk2] ~ a [W] F a ~ fsk2 --> [W] F [fsk2] ~ fsk2 -- Back to square 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 20:49:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 20:49:41 -0000 Subject: [GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes In-Reply-To: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> References: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> Message-ID: <062.6a58f21388f9e6444c81b47592eb143f@haskell.org> #9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | 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 simonpj): See also #4347, #4295, #7264, #8808, #9420 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 22:02:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 22:02:16 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine Message-ID: <054.1a3de7e547d9846e701648e955069452@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: MikolajKonarski | 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: Installing Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is basically the same problem as reported here: https://www.mail-archive.com/ghc-devs at haskell.org/msg04439.html I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs I've downloaded http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux- deb7.tar.xz configured, and make install says: {{{ Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn' Installing library in /mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0 "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 22:18:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 22:18:59 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.794fbdca043cb3bf3caaf8e6bb6445ab@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 22:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 22:47:03 -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.82051e2aacd64a7cf30735c7482229ec@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): Replying to [comment:2 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? Sorry, I've been a tad confused, as usual. The problem, I now see, is the bunch of thunks we produce. I don't think it's possible to make `scanr` a good producer, and I'm not even sure we can make it a significantly better one (though I'd have to profile to be sure). What we ''can'' do, in an apparently incompatible fashion, is make it a good consumer. Start with the current tail-eating implementation: {{{#!hs scanr _ q0 [] = [q0] scanr f qo (x:xs) = f x q : qs where qs@(q:_) = scanr f q0 xs }}} Rewriting that pattern match thing more explicitly: {{{#!hs scanr f q0 (x:xs) = let qs = scanr f q0 xs in f x (head qs) : qs }}} This, then is a plain old fold: {{{#!hs scanr f q0 = foldr go [q0] xs where go x qs = f x (head qs) : qs }}} If we apply it to a `build`, we get {{{#!hs scanr f q0 (build g) = g go [q0] where go x qs = f x (head qs):qs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 23:17:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 23:17:55 -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.8657afba7e671bf4fbf3c2712d296503@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): Since `foldr` is strict in its list argument, I think it's then safe to go back to the pattern match style: {{{#!hs scanr f q0 = foldr go [q0] xs where go x qs@(q:_) = f x q : qs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 23:24:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 23:24:36 -0000 Subject: [GHC] #9422: EPT caching on --make can make spurious instances visible Message-ID: <045.91a3ec26e8fbfdfd2348192932411b44@haskell.org> #9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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: -------------------------------------+------------------------------------- This is perhaps best demonstrated by way of an example. Suppose we have a package a with the following two modules, with A defining a type class and data type, and I defining an orphan instance. {{{#!hs module A where data A = A class C a where cop :: a -> a }}} {{{#!hs module I where import A instance C A where cop = id }}} Then, when compiling this module: {{{#!hs module N where import A x = cop A }}} I might reasonably expect to be told that the instance `C` is not in scope (since I didn't import `I`, nor did any of my dependencies import `I`). However, suppose I have another module: {{{#!hs module M where import I }}} and I use `--make` to compile both of these modules in one go, with `M` being compiled first (`ghc --make N.hs M.hs` does that for me), then `N` will incorrectly type check and compile! This should not happen. The reason for this behavior is that we do not clear the EPT (external package table) between compilations of a file in batch compilation mode; this saves us from having to repeatedly read instances from the external files. Thus, `M`, having loaded the instances into the EPT when type- checking, `N` will automatically pick them up. Note that `I` and `A` have to be in a separate package; otherwise `--make` puts them in the HPT (home package table) and everything works fine. (Note also that one-shot compilation puts home modules in the EPT, but since that gets thrown out everything is fine as well, although perhaps a user of the GHC API could get bitten by this.) As for the fix, it's probably not right to clear the EPT either, since we get quite good time savings from not having to parse interface files repeatedly. Perhaps we could do something clever by partitioning up the EPT, but maybe it's not worth it and we should keep this bug as a known infelicity until the next time this part of the compiler gets rewritten. I'll submit a test-case (marked as failing) anyhoo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 23:27:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 23:27:46 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() Message-ID: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: 9284 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs. The problem has only been observed on OS X, though it probably could occur on Linux OSes as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 7 23:29:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Aug 2014 23:29:59 -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.7ed20e73e0cf5993d962f82e8ad24606@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: | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I created a new issue #9423 for the problem when caused by a call to `hs_exit`. Now we can treat the issue here as being specific to `forkProcess`. Since we have a fix for this (I believe) we can close this ticket independently of #9423. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 00:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 00:12: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.3a5105e37b82e418901e93b2a60c3923@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): The patch didn't do anything (although I only applied it and re-`make && make install`-ed it. Should I have done a full `make clean && configure ...`?) However, LLVM 3.4 seems to work. It at least produces {{{ 29.0 }}} when fed {{{ main = print (29.0 :: Float) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 00:20:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 00:20:28 -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.34a75650772cc1b0b43b65e3b1ad58e9@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:24 amurrayc]: > The patch didn't do anything (although I only applied it and re-`make && make install`-ed it. Should I have done a full `make clean && configure ...`?) You don't need to rerun `configure`, but yeah you will need to rebuild the stage1 compiler so that it can rebuild the RTS correctly, and `make clean` is the easiest way. > However, LLVM 3.4 seems to work. It at least produces > {{{ > 29.0 > }}} > when fed > {{{ > main = print (29.0 :: Float) > }}} Well that's good to know, at least! I still think our TBAA information is wrong for this code, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 00:42:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 00:42:32 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.fb44070c3b4900d3dc14a2b3a45c3558@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Now that we've discussed this to death, I think it's time to close it up as a lesson learned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 08:04:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 08:04: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.b1a720a61e08490f5d273444aace4f79@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:"dff0623d5ab13222c06b3ff6b32793e05b417970/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dff0623d5ab13222c06b3ff6b32793e05b417970" Implement the final change to INCOHERENT from Trac #9242 The change here is to make INCOHERENT slightly more permissive: if the selected candidate is incoherent then ignore all unifying candidates This allows us to move the {-# INCOHERENT #-} pragma from from instance Typeable (f a) to Typeable (n:Nat) and Typable (s:Symbol) where it belongs, and where Trac #9242 said it should be. I don't think this will affect anyone. I've updated the user manual. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 08:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 08:09:13 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.7cdd25c8fc7cb8ea122aaa23a6e1c51c@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I have finally done the INCOHERENT thing. I'll close this ticket. There are some loose ends which I'll list here: * David, if you want to open a new ticket for OVERLAPS, by all means do so, if you think you've got a good proposal with user support. * I'd like to make `-XUndecideableInstances` a per-instance pragma, instead of a module-wide LANGUAGE flag. That would be consistent with this `OVERLAPPABLE` stuff. Anyone want to do that? * At least one person suggested that there should be a LANGUAGE pragma that switches on recognition of the per-instance pragmas. So `{-# OVERLAPPABLE #-}` is only honoured if you have `-XHonourOverlappingInstnaces` or something. Personally I think this is too much, but users may differ! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 10:03:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 10:03:13 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.8948489871e23987ead0d8bcb037cd91@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by tibbe): It looks like the overflow isn't in `shouldInlinePrimOp` (although that function should be fixed too) but in the code that create the `CmmInt` literal. Adding this tracing {{{ shouldInlinePrimOp dflags NewByteArrayOp_Char [(CmmLit (CmmInt n _))] | n <= fromIntegral (maxInlineAllocSize dflags) = trace ("matches " ++ show n) $ }}} shows that `n` is -40, even thought it's an Integer, suggesting that the wrap-around happened elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 10:08:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 10:08:51 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.8f91207d50c454e90d9934f33c291b24@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by tibbe): The core confirms my suspicions: {{{ case GHC.Prim.newByteArray# @ GHC.Prim.RealWorld (-40) s1_a1Cc }}} The only workaround I can think of is quite unpleasant. We need to cast the `Integer` in the `CmmInt` to a `Word`(and then perhaps back to an `Integer`) to get rid of the 2-complement interpretation of the value. The real fix is to change `newByteArray#` to take the size as a `Word#`. I don't see how the overflow1 test ever passed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 10:20:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 10:20:18 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.4500bfd647c3d6d5eb1c1217efd49684@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by tibbe): If we disable `shouldInlinePrimOp` altogether we get this Cmm: {{{ R1 = (-40); Sp = Sp - 8; call stg_newByteArray#(R1) returns to c3Nu, args: 8, res: 8, upd: 8; }}} Presumably `stg_newByteArrayzh` interprets its argument as an unsigned quantity and thus the test passes without `shouldInlinePrimOp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 11:04:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 11:04:48 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.225675fe88bbf673e511b6f504fe9c38@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): OK, I've put together a draft of a document explaining what we've discussed in this ticket: https://www.fpcomplete.com/tutorial-preview/4431/z0KpB0ai2R Comments (and especially corrections) highly welcome! There's one thing in particular I wasn't sure of: why is `lazy` necessary in the definition of `unsafeDupablePerformIO`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 11:36:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 11:36:54 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.33885409e160785a6f139465a11ef719@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Some quick comments (I'm about to go on holiday): * You shouldn't have to quote the documentation for `pseq` to understand `seq`. If `seq`'s documentation is inadequate, let's fix it. * You say "seq ensures that both one and one + two will be evaluated before the seq expression is evaluated". I would rather say "...before the result of the seq expression is ''returned''". * "We can get the same guaranteed ordering of evaluation by having a function which is only strict in one of its arguments". Definitely not! GHC will inline `add` and all will be lost. Only `pseq` guarantees this behaviour. * Passage starting "This looks like it should be straightforward". Alas you have found yet another dark corner. Here is a comment from the demand analyser: {{{ -- Note [IO hack in the demand analyser] -- -- There's a hack here for I/O operations. Consider -- case foo x s of { (# s, r #) -> y } -- Is this strict in 'y'. Normally yes, but what if 'foo' is an I/O -- operation that simply terminates the program (not in an erroneous way)? -- In that case we should not evaluate y before the call to 'foo'. -- Hackish solution: spot the IO-like situation and add a virtual branch, -- as if we had -- case foo x s of -- (# s, r #) -> y -- other -> return () -- So the 'y' isn't necessarily going to be evaluated -- -- A more complete example (Trac #148, #1592) where this shows up is: -- do { let len = ; -- ; when (...) (exitWith ExitSuccess) -- ; print len } }}} You can look at the tickets mentioned for some more background. I hate the hack, but the bottom line is that no, GHC does not (and I think should not) evaluate helper2 before running helper1. That's as far as I got. Thanks for writing this -- it's a good forcing function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 11:47:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 11:47:40 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.957578557756df3d7de2d8a76f0800e6@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: D128 | -------------------------------------+------------------------------------- Changes (by tibbe): * status: new => patch * differential: => D128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 12:08:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 12:08:33 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.6f61c6b5f8a654d3a32a018108153050@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Thanks for the review, and enjoy the vacation. Some responses: * I've added a note to myself to send a pull request on the documentation of `seq` next week. * I've updated the text as you indicated. * Thank you for clarifying. I've left the example that I originally had, but instead of saying "this will work too," it says "you might think this will work, but due to inlining, it won't." * I'm confused about this last part, because the situation I'm describing seems to be *exactly* the bug that Carter reports in comment 2. Your explanation here implies to me that we never really fully explained why Carter's code is acting as it does, though I can guess that it is in fact another manifestation of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 12:12:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 12:12:44 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.4ca69ddfb20fadc262c798d6f8fc91b9@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Great work. I'm going to add some top level comments here * I'd love a wiki page summarising the programmer's-eye-view of the design; and sketching the implementation. You may say that the programmer's eye view is in the paper, but (a) that's less accessible, and (b) details change, such as the type, which you have called `Ref`. * Bikeshed: I don't that is at all a good name... sounds mutable to me. I don't think `Static t` so bad. `StaticName` is ok, as is `StaticPtr`. * The type checker is not supposed to do program transformations like floating bindings to top level. It should be possible to display the output of the type checker in an IDE, exactly as the programmer wrote it, fully decorated with type information. So I think it'd be better if the desugarer did the floating, not the type checker. That should not be a hard change to make. * I don't understand `checkStaticValues`. The typing rule for `static` in the paper is quite simple, so what is going on here? * What is `addrToAny#` and where is it documented? * I'm pretty convinced that static values (`Refs`) should come with a `TypeRep` -- or at least the fingerprint of a `TypeRep` so that we can reject bogus values. That wouldn't be hard, would it? The merit of having a `TypeRep` tree rather than just a fingerprint is that the error message might be more informative. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 12:17:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 12:17:07 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.ac0b6da42ce533549249fb37ef5f2866@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 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): This is the dreaded `SpecConstr` blowup again (see #8980, #8941 (possibly), #8960, #7898, #7068, #7944, #5550, #8836). Compiling with `-fno-spec-constr` makes it go through fine, so that's a workaround. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:07:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:07:50 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.4d4512198a14e6d6cb312fe937ccb6cd@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edwinhere): * owner: igloo => * status: closed => new * version: 7.4.1 => 7.8.1-rc2 * resolution: fixed => * milestone: 7.6.2 => Comment: We need to reopen this for hsc2hs version 0.67 and GHC version 7.8.3 into Haskell platform 2014.2.0.0 for Windows. I am still getting the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:11:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:11:57 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.4bdb0406110ed77c2ff1882259d0d6a7@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 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): I made a little progress here. First, `SpecConstr` is not generating lots of code! In fact it is doing no specialisation whatsoever. BUT it is nevertheless taking a very long time to do, well, nothing. So something is afoot. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:21:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:21:39 -0000 Subject: [GHC] #9424: ghc-api/T8628 fails assert on debugged ghc Message-ID: <045.40c90e35dc60386a27fb2e3ed744169b@haskell.org> #9424: ghc-api/T8628 fails assert on debugged ghc -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- ./validate --slow fails thusly: {{{ Unexpected failures: ghc-api T8628 [bad stderr] (normal) # run by hands: $ LANG=C make fulltest stage=2 TEST=T8628 =====> T8628(normal) 3453 of 4083 [0, 0, 0] cd ./ghc-api && $MAKE -s --no-print-directory T8628 T8628.run.stdout 2>T8628.run.stderr Actual stderr output differs from expected: --- /dev/null 2014-06-09 18:31:31.993762230 +0300 +++ ./ghc-api/T8628.run.stderr 2014-08-08 16:02:17.000000000 +0300 @@ -0,0 +1,2 @@ +WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fShowX +WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fShowX *** unexpected failure for T8628(normal) }}} '''compiler/simplCore/SimplEnv.lhs:539''' {{{#!hs refine :: InScopeSet -> Var -> Var refine in_scope v | isLocalId v = case lookupInScope in_scope v of Just v' -> v' {- 539 -} Nothing -> WARN( True, ppr v ) v -- This is an error! | otherwise = v }}} Is it really a bug as comment suggests? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:33:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:33:09 -0000 Subject: [GHC] #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit-yields mode Message-ID: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit- yields mode -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- Found on '''./validate --slow''' today: {{{#!hs Unexpected failures: concurrent/should_run T367_letnoescape [bad exit code] (optllvm) # run manually: $ LANG=C make fulltest stage=2 TEST=T367_letnoescape WAY=optllvm =====> T367_letnoescape(optllvm) 2419 of 4083 [0, 0, 0] cd ./concurrent/should_run && '/home/st/fun/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o T367_letnoescape T367_letnoescape.hs -O -fllvm -fno-omit-yields >T367_letnoescape.comp.stderr 2>&1 cd ./concurrent/should_run && ./T367_letnoescape T367_letnoescape.run.stdout 2>T367_letnoescape.run.stderr Timeout happened...killing process... Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: *** unexpected failure for T367_letnoescape(optllvm) }}} I've loaded test in gdb and manually interrupted it: {{{ ^C Program received signal SIGINT, Interrupt. 0x0000000000407110 in r5Wp_info () (gdb) disassemble Dump of assembler code for function r5Wp_info: 0x00000000004070f8 <+0>: mov 0x358(%r13),%rax 0x00000000004070ff <+7>: dec %r14 0x0000000000407102 <+10>: data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) => 0x0000000000407110 <+24>: inc %r14 0x0000000000407113 <+27>: test %rax,%rax 0x0000000000407116 <+30>: jne 0x407110 0x0000000000407118 <+32>: mov -0x8(%r13),%rax 0x000000000040711c <+36>: mov $0x8e0690,%ebx 0x0000000000407121 <+41>: jmpq *%rax End of assembler dump }}} Here we see 3 instructions-long dead loop. llvm-3.4.2, amd64-linux. Looks like yield code was not emitted or was moved away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:33:30 -0000 Subject: [GHC] #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit-yields mode In-Reply-To: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> References: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> Message-ID: <060.242a40096075c66b226cce1f25185936@haskell.org> #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit- yields mode -------------------------------------+------------------------------------- Reporter: slyfox | 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 slyfox: Old description: > Found on '''./validate --slow''' today: > > {{{#!hs > Unexpected failures: > concurrent/should_run T367_letnoescape [bad exit code] (optllvm) > > # run manually: > $ LANG=C make fulltest stage=2 TEST=T367_letnoescape WAY=optllvm > > =====> T367_letnoescape(optllvm) 2419 of 4083 [0, 0, 0] > cd ./concurrent/should_run && '/home/st/fun/ghc/inplace/bin/ghc-stage2' > -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- > db -rtsopts -fno-ghci-history -o T367_letnoescape T367_letnoescape.hs -O > -fllvm -fno-omit-yields >T367_letnoescape.comp.stderr 2>&1 > cd ./concurrent/should_run && ./T367_letnoescape >T367_letnoescape.run.stdout 2>T367_letnoescape.run.stderr > Timeout happened...killing process... > Wrong exit code (expected 0 , actual 99 ) > Stdout: > > Stderr: > > *** unexpected failure for T367_letnoescape(optllvm) > }}} > > I've loaded test in gdb and manually interrupted it: > {{{ > ^C > Program received signal SIGINT, Interrupt. > 0x0000000000407110 in r5Wp_info () > (gdb) disassemble > Dump of assembler code for function r5Wp_info: > 0x00000000004070f8 <+0>: mov 0x358(%r13),%rax > 0x00000000004070ff <+7>: dec %r14 > 0x0000000000407102 <+10>: data32 data32 data32 data32 nopw > %cs:0x0(%rax,%rax,1) > > => 0x0000000000407110 <+24>: inc %r14 > 0x0000000000407113 <+27>: test %rax,%rax > 0x0000000000407116 <+30>: jne 0x407110 > > 0x0000000000407118 <+32>: mov -0x8(%r13),%rax > 0x000000000040711c <+36>: mov $0x8e0690,%ebx > 0x0000000000407121 <+41>: jmpq *%rax > End of assembler dump > }}} > > Here we see 3 instructions-long dead loop. > > llvm-3.4.2, amd64-linux. > > Looks like yield code was not emitted or was moved away. New description: Found on '''./validate --slow''' today: {{{ Unexpected failures: concurrent/should_run T367_letnoescape [bad exit code] (optllvm) # run manually: $ LANG=C make fulltest stage=2 TEST=T367_letnoescape WAY=optllvm =====> T367_letnoescape(optllvm) 2419 of 4083 [0, 0, 0] cd ./concurrent/should_run && '/home/st/fun/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o T367_letnoescape T367_letnoescape.hs -O -fllvm -fno-omit-yields >T367_letnoescape.comp.stderr 2>&1 cd ./concurrent/should_run && ./T367_letnoescape T367_letnoescape.run.stdout 2>T367_letnoescape.run.stderr Timeout happened...killing process... Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: *** unexpected failure for T367_letnoescape(optllvm) }}} I've loaded test in gdb and manually interrupted it: {{{ ^C Program received signal SIGINT, Interrupt. 0x0000000000407110 in r5Wp_info () (gdb) disassemble Dump of assembler code for function r5Wp_info: 0x00000000004070f8 <+0>: mov 0x358(%r13),%rax 0x00000000004070ff <+7>: dec %r14 0x0000000000407102 <+10>: data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) => 0x0000000000407110 <+24>: inc %r14 0x0000000000407113 <+27>: test %rax,%rax 0x0000000000407116 <+30>: jne 0x407110 0x0000000000407118 <+32>: mov -0x8(%r13),%rax 0x000000000040711c <+36>: mov $0x8e0690,%ebx 0x0000000000407121 <+41>: jmpq *%rax End of assembler dump }}} Here we see 3 instructions-long dead loop. llvm-3.4.2, amd64-linux. Looks like yield code was not emitted or was moved away. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 13:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 13:53:25 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.a8c4e796d61804975fc752885c4e9c42@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Replying to [comment:12 simonpj]: > * I'd love a wiki page summarising the programmer's-eye-view of the design; ... Good suggestion. > * What is `addrToAny#` and where is it documented? Found here: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html#v:addrToAny-35- > * ... So I think it'd be better if the desugarer did the floating, not the type checker. That should not be a hard change to make. Sure, we can try it. > * I don't understand `checkStaticValues`. The typing rule for `static` in the paper is quite simple, so what is going on here? One of the major design choices we had to make is how to handle qualified types. Say we have the expression `static return`, we had to choose between giving it types like: {{{ static return :: Ref (Monad m => a -> m a) static return :: Monad m => Ref (a -> m a) }}} or disallowed them completely. The last option looked the simplest while still useful, so we disallowed static forms whose bodies have qualified types. Now, say we want to type- check an expression like {{{ f :: Ref (a -> IO a) f = static return }}} We expect the expression `return` to have type `a -> IO a`. Yet we don't know if the type of `return` will be qualified or not until the whole definition of `f` is type-checked. `f` could have more equations and no type signature, or we may even have to wait for the whole module to be type-checked because of the monomorphism restriction. `checkStaticValues` is the piece of the implementation that considers if the body of the static form has a qualified type. And this, we understand, is only practical to do after the whole module has been type-checked. > * I'm pretty convinced that static values (`Refs`) should come with a `TypeRep` ... In case you mean Data.Typeable.TypeRep, how could we deal with static forms whose bodies have a polymorphic type? > Bikeshed: ... I leave this for later. Thanks for looking at the implementation. It really needs the feedback. And probably, we should document better the design and discuss it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 14:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 14:01:47 -0000 Subject: [GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' Message-ID: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- Found by '''./validate --slow''': {{{ Unexpected failures: ghci/scripts ghci044 [bad stderr] (ghci) ghci/scripts ghci047 [bad stderr] (ghci) # run manially: $ LANG=C make fulltest stage=2 TEST="ghci044 ghci047" =====> ghci047(ghci) 87 of 4083 [0, 1, 0] cd ./ghci/scripts && HC='/home/st/fun/ghc/inplace/bin/ghc-stage2' HC_OPTS ='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/st/fun/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 ghci047.run.stdout 2>ghci047.run.stderr Actual stderr output differs from expected: --- ./ghci/scripts/ghci047.stderr 2014-07-31 12:05:34.000000000 +0300 +++ ./ghci/scripts/ghci047.run.stderr 2014-08-08 16:58:01.000000000 +0300 @@ -1,16 +1,14 @@ +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906 -:38:1: - Couldn't match type ?HFalse? with ?HTrue? - Expected type: HTrue - Actual type: Or HFalse HFalse - In the expression: f - In the expression: f $ Baz 'a' - In an equation for ?it?: it = f $ Baz 'a' - -:39:1: - Couldn't match type ?HFalse? with ?HTrue? - Expected type: HTrue - Actual type: Or HFalse HFalse - In the expression: f - In the expression: f $ Quz - In an equation for ?it?: it = f $ Quz +:36:1: Not in scope: ?f? + +:37:1: Not in scope: ?f? + +:38:1: Not in scope: ?f? + +:39:1: Not in scope: ?f? + +:40:1: Not in scope: ?f? + +:41:1: Not in scope: ?f? Actual stdout output differs from expected: --- ./ghci/scripts/ghci047.stdout 2014-07-31 12:05:34.000000000 +0300 +++ ./ghci/scripts/ghci047.run.stdout 2014-08-08 16:58:01.000000000 +0300 @@ -1,4 +0,0 @@ -1 -1 -1 -1 *** unexpected failure for ghci047(ghci) }}} The trigger in '''compiler/ghci/Linker.lhs:906''': {{{#!hs linkSomeBCOs dflags toplevs_only ie ce_in ul_bcos = do let nms = map unlinkedBCOName ul_bcos hvals <- fixIO ( \ hvs -> let ce_out = extendClosureEnv ce_in (zipLazy nms hvs) in mapM (linkBCO dflags ie ce_out) ul_bcos ) let ce_all_additions = zip nms hvals ce_top_additions = filter (isExternalName.fst) ce_all_additions ce_additions = if toplevs_only then ce_top_additions else ce_all_additions ce_out = -- make sure we're not inserting duplicate names into the -- closure environment, which leads to trouble. {- 906 -} ASSERT(all (not . (`elemNameEnv` ce_in)) (map fst ce_additions)) extendClosureEnv ce_in ce_additions return (ce_out, hvals) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 14:44:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 14:44:46 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.4544d32332b0c2672e25d0052ad289d1@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @snoyberg, does the fpco website run the inline code at O0? the inlinePerformIO example in the document gives the A B result rather than the shared result! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 14:49:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 14:49:02 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.f38fbef105f8dd6479744554cae1927b@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: D128 | -------------------------------------+------------------------------------- Comment (by carter): is the Int/word issue related to https://ghc.haskell.org/trac/ghc/ticket/8299 ? (ie because we don't have the richer distinction between how we use ints and words for address manipulation?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 15:11:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 15:11:30 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.62933301f7e292baeb75558f42245360@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): @carter: It runs it with GHCi (or close enough), so none of the rearranging of code will occur. I added a comment towards the top of the article explaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 15:28:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 15:28:06 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.a3e4a68fbbbba8309e329112b5995b67@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: simonmar AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): The attached program illustrates the problem. Compile like this, where `` should be a recent (7.8.x) GHC: {{{ -c Foo.hs -threaded -no-hs-main FooMain.c Foo.o }}} Then run `a.out`. You should see some printouts and then it should hang (i.e. fail to terminate). You may need to run it a few times t see the behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 19:14:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 19:14:03 -0000 Subject: [GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations Message-ID: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- In the resolution to #9200, as detailed [wiki:GhcKinds/KindInference#Apossiblevariation here], we identified an area for improvement. This improvement was not implemented in the fix for #9200. This ticket will track just this improvement. (In brief: we can do better dependency analysis on mutually recursive type/class declarations to allow more kinds to generalize earlier. This would lessen the burden on programmers to put in kind annotations. See the wiki page.) A solid but unfinished attempt is [https://github.com/goldfirere/ghc/tree /re-sort-non-cusk-decls here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 19:14:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 19:14:29 -0000 Subject: [GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations In-Reply-To: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> References: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> Message-ID: <062.cd84dca5d4ed8f0eb4ba33bfcca3ee1f@haskell.org> #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 20:09:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 20:09:16 -0000 Subject: [GHC] #9428: Pretty printer bad formatting Message-ID: <047.0c4467a917eff36078c41806463d1f16@haskell.org> #9428: Pretty printer bad formatting -------------------------------------+------------------------------------- Reporter: terrelln | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Driver | Version: 7.6.3 Keywords: pretty print | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with `-fwarn-incomplete-patterns`, the first test case `s17.hs` (attached) outputs unmatched patterns correctly. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B A B ... }}} However, when compiling `s18.hs` each argument is printed on its own line. 16 lines of the output are included below. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 22:29:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 22:29:58 -0000 Subject: [GHC] #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit-yields mode In-Reply-To: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> References: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> Message-ID: <060.dd0168284fc487054dc8ded76c491484@haskell.org> #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit- yields mode -------------------------------------+------------------------------------- Reporter: slyfox | 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 rwbarton): LLVM assumes that `HpLim` (which is located at `0x358(%r13)`) is not changing during the loop. We need to emit whatever LLVM assembly language construction tells LLVM to assume that `HpLim` might change (`load volatile` perhaps?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 22:41:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 22:41:00 -0000 Subject: [GHC] #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit-yields mode In-Reply-To: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> References: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> Message-ID: <060.86729180c2cbdc4d8939737eb0a8ff0e@haskell.org> #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit- yields mode -------------------------------------+------------------------------------- Reporter: slyfox | 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 rwbarton): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 8 23:59:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Aug 2014 23:59:41 -0000 Subject: [GHC] #1631: Make the External Package Table contain ModDetails not ModIface In-Reply-To: <046.eed09ce365177007f04f67ce514c6ba5@haskell.org> References: <046.eed09ce365177007f04f67ce514c6ba5@haskell.org> Message-ID: <061.1c4f2e33d95413dbb437cc60d496a34a@haskell.org> #1631: Make the External Package Table contain ModDetails not ModIface -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.6.1 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 ezyang): * owner: => ezyang Comment: I need this for #9252: here, we may have a module in the EPT which we want to compare against an hsig we compiled locally, and we need a full `ModDetails` for this comparison and not just a stubbed out `ModIface`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 9 00:08:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Aug 2014 00:08:51 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.ab8ad2765c8f77daa2a23659e12cfefc@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 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: | https://phabricator.haskell.org/D130| -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => https://phabricator.haskell.org/D130 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 9 04:45:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Aug 2014 04:45:22 -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.887e35d9e02287ab49601a8a08d312dc@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:25 rwbarton]: > Replying to [comment:24 amurrayc]: > > The patch didn't do anything (although I only applied it and re-`make && make install`-ed it. Should I have done a full `make clean && configure ...`?) > > You don't need to rerun `configure`, but yeah you will need to rebuild the stage1 compiler so that it can rebuild the RTS correctly, and `make clean` is the easiest way. Okay, finally done. The patch (properly remade) doesn't seem to improve things with LLVM 3.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 9 19:44:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Aug 2014 19:44:39 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.a0ae787b3787172c99d8611c8f11cc1b@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | 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 Reid Barton ): In [changeset:"caa9c8aa7d17af04e16070e15ba274da0ab93247/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="caa9c8aa7d17af04e16070e15ba274da0ab93247" Add test case for #9013 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:02:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:02:07 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.d7fd3b6904f6b8b5a60706ba1ae8fab2@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I've submitted a differential (is that the right term?) on Phabricator for improvements to the `seq` documentation: https://phabricator.haskell.org/D136 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:07:00 -0000 Subject: [GHC] #9429: Alternative to type family Any Message-ID: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | 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: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:08:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:08:00 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.476e0ea54ec4fe983fcc45b387350e3b@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by mboes: Old description: > In GHC HEAD, `Any` is no longer a datatype. There are good reasons for > this change, one of which was explained in #9097, the original ticket, > and another in #9380. Unfortunately, a casualty of this change is that it > is no longer easy to generalize the > [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] > to rank-1 types with type variables of arbitrary kind (not just `*`). We > submitted a way to do so [here], that exploits the fact that `Any` has > the very magical property of inhabiting *all* kinds, including closed > ones. > > This works for GHC 7.8, but won't work in HEAD, because we require that > there exists a `Typeable` instance for `Any`, just as there are > `Typeable` instances for any other type one wishes to have instances for. > The reason is that now that `Any` is a type family, `Any` is no longer a > legal instance head. > > There are several possible solutions that I see: > * while it's clearly dangerous for the compiler to be inserting the old > `Any` during typechecking from the moment that we have computation in > types over closed kinds, we may still want the old `Any`, say under a > different name, as a backdoor. It wouldn't be used by the compiler during > type checking - only by packages such as rank1dynamic. I believe that > furthermore, if we restrict the old `Any` to not inhabit closed kinds, > then none of the problems cited in the above tickets arise. > * Instead of making the new `Any` a type family, keep it a datatype, but > ban it from inhabiting closed kinds. I don't know if such an `Any` would > be sufficient for the purposes of GHC, however. > * Hardwire a `Typeable` instance for the `Any` type family (not sure if > this makes sense). New description: In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [https://github.com/haskell- distributed/rank1dynamic/pull/6|here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:10:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:10:06 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.1e6f6db5f9760a03ad44385ccdd52446@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by mboes: Old description: > In GHC HEAD, `Any` is no longer a datatype. There are good reasons for > this change, one of which was explained in #9097, the original ticket, > and another in #9380. Unfortunately, a casualty of this change is that it > is no longer easy to generalize the > [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] > to rank-1 types with type variables of arbitrary kind (not just `*`). We > submitted a way to do so [https://github.com/haskell- > distributed/rank1dynamic/pull/6|here], that exploits the fact that `Any` > has the very magical property of inhabiting *all* kinds, including closed > ones. > > This works for GHC 7.8, but won't work in HEAD, because we require that > there exists a `Typeable` instance for `Any`, just as there are > `Typeable` instances for any other type one wishes to have instances for. > The reason is that now that `Any` is a type family, `Any` is no longer a > legal instance head. > > There are several possible solutions that I see: > * while it's clearly dangerous for the compiler to be inserting the old > `Any` during typechecking from the moment that we have computation in > types over closed kinds, we may still want the old `Any`, say under a > different name, as a backdoor. It wouldn't be used by the compiler during > type checking - only by packages such as rank1dynamic. I believe that > furthermore, if we restrict the old `Any` to not inhabit closed kinds, > then none of the problems cited in the above tickets arise. > * Instead of making the new `Any` a type family, keep it a datatype, but > ban it from inhabiting closed kinds. I don't know if such an `Any` would > be sufficient for the purposes of GHC, however. > * Hardwire a `Typeable` instance for the `Any` type family (not sure if > this makes sense). New description: In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [https://github.com/haskell- distributed/rank1dynamic/pull/6 here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:11:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:11:54 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.de95624519875499034d70355bd15959@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): Fixed link to rank1dynamic pull request: https://github.com/haskell- distributed/rank1dynamic/pull/6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 11:14:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 11:14:58 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.a3471862226bca03b43505fb5d20f2e0@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by jrp): Today's results from a fast bindist build. {{{ Unexpected results from: TEST="T367_letnoescape T9379 conc012 overflow1 T5435_dyn_asm T5321FD T5030 T4801 T6048 T5631 T783 T5642 T9020 T3064 parsing001 T1969 T5321Fun T5837 T3294 cabal06 enum01 topHandler03 enum03 enum02" OVERALL SUMMARY for test run started at Sun Aug 10 11:25:55 2014 BST 0:32:58 spent to go through 4059 total tests, which gave rise to 15828 test cases, of which 3379 were skipped 299 had missing libraries 11938 expected passes 153 expected failures 3 caused framework failures 0 unexpected passes 56 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/cabal06 cabal06 [bad stdout] (normal) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run T9379 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) concurrent/should_run T9379 [bad stdout or stderr] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) rts T5435_dyn_asm [bad stdout] (normal) rts overflow1 [bad exit code] (hpc,optasm,threaded2,dyn,optllvm) }}} Some of these tests pass if I run fulltst with the build tree, rather than bindist, version: {{{ Unexpected results from: TEST="T367_letnoescape conc012 overflow1 T5435_dyn_asm T5321FD T5030 T4801 T6048 T5631 T5837 T5642 T9020 T3064 parsing001 T1969 T5321Fun T783 T3294 cabal06 enum01 topHandler03 enum03 enum02" OVERALL SUMMARY for test run started at Sun Aug 10 12:02:27 2014 BST 0:07:21 spent to go through 4085 total tests, which gave rise to 16029 test cases, of which 15949 were skipped 0 had missing libraries 32 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 48 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/cabal06 cabal06 [bad stdout] (normal) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) rts T5435_dyn_asm [bad stdout] (normal) rts overflow1 [bad exit code] (hpc,optasm,threaded2,dyn,optllvm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 12:37:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 12:37:48 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.e81147baa8de81a605d7ae688d46363e@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 13:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 13:10:27 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.5087f76caeee299902ffd80003cb43b4@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): Hm, perhaps I was a bit too hasty about the "inhabiting only open kinds" criterion as being sufficient for safety. In #9380, we have a GADT indexed by types in a closed kind. But the breaking test case exposed there would break just as well with an open kind, I think. The problem is that GHC chooses `Any` as an arbitrary instantiation for some unbound type variable appearing in the type index of the GADT, which then leads GHC to wrongly identify some alternatives as being "unreachable" in case analyses. Therefore, the second solution in the description of this ticket would still have problems with GADT's. I guess my point is that while the `Any` that GHC uses to silently instantiate things during type checking should be well behaved, clearly, there could be an `UnsafeAny`, similar to the old `Any`, for certain targeted use cases such as obtaining the `TypeRep` of a polymorphic type with no type families. For polymorphic types where there ''might'' be occurrences of type families, I so no other solution but to somehow make the `Any`-the-type-family `Typeable` somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 15:19:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 15:19:37 -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.12a4fd38016adf8e519df937fd3b2d3b@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): Curious. Would you mind extracting the `.cmm` and `.ll` and `.o` files in the same way as before, so I can make sure the patch is having the expected effect? If it is then I think we can declare this to be a bug in LLVM 3.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 17:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 17:11:58 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.f1fa7ec3cf0052fa80bab9a09fffd6f3@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------- Reporter: pumpkin | 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 rwbarton): In fact it's even more involved than I originally thought. `MO_Add2` invokes the code generator for `MO_Add` to do the first addition. `MO_Add` sees that the second argument is constant so it can produce an `LEA` instruction (which wouldn't set the carry flag). The pretty-printer notices that the source and destination registers of the `LEA` instruction are the same, so it rewrites it to an `ADD` (which would set the carry flag); and then it notices that the addend is -1, so it finally emits `dec` (which doesn't set the carry flag). All of what the code generator does for `MO_Add` is fine, since the semantics of `MO_Add` don't include any effect (or lack thereof) on the condition register. The error is in the code generation for `MO_Add2`: it should not use `MO_Add`, for this reason. I will put up a patch for review shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 18:28:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 18:28:34 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.db7814817aace6e091fcea0a625cf397@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------- Reporter: pumpkin | 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: Phab:D137 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D137 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:07:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:07:54 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.550774045fddfc46c69f9da1c5f7fc18@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) | 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 diatchki): I've chatted with Mark and Garrett (the authors of the "Instance Chains" papers) and we've decided that there are really three separate features here: 1. "Instance Groups", which is what is outlined in this ticket, and enables programmers to order instances explicitly, rather than using more/less general realtions. 2. "Fails instances", which are of the form `instance Num Char fails`; they enable programmers to state explicitly that an instance should never exits. Interestingly, I just found a very related ticket asking for the same sort of thing (#7775). 3. "Using instance contexts when selecting instances (aka backtracking)": currently, if the head of an instance matches a goal, GHC commits to it and then fails if it encounters an error; an alternative design would be to back-track and try a different option (e.g., next member of an instance group, or a more general matching instance). I think that (1) and (2) are useful and shouldn't be too hard to implement in GHC. (3), however, seems like more work. Also, there are programs that rely on GHC's current behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:13:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:13: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.07245370a562c271277f2b72d122b051@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): I'm just about to attach them. Would it help to see those files for the 3.4 build too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:21:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:21:39 -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.4a62b9f96fa5f2429b1fec4065cf9bce@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): Hopefully the `.cmm` and `.ll` files will be the same, but sure, let's have the 3.4 `.o` file too for the record. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:31:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:31:12 -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.3670964320a4f33d6251c232f2e58343@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): Oops, I just realised that the first set of files I attached were from the device build but, as I've been away from my iPad for a few days the version I generated now is for the simulator. Both have been misbehaving in the same way though. I'm back with the device but I have to recompile the device version from scratch. I'll attach the simulator files. I can get the device files too but it'll take a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:53:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:53:36 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled In-Reply-To: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> References: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> Message-ID: <059.717ea6a8400c55524e6cff52043fad52@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: pthread staticlib Operating System: MacOS X | threaded Type of failure: Compile- | Architecture: x86 time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D120 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8d90ffae3a3c0d7c9ac8800ae91887aeaa9917d3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8d90ffae3a3c0d7c9ac8800ae91887aeaa9917d3" fix darwin threaded static linking by removing -lpthread option #9189 Summary: Signed-off-by: Bob Ippolito Test Plan: See repro instructions in trac #9189 Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D120 GHC Trac Issues: #9189 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:54:25 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.2b54adc6ca10ffaa05e7612136396cb9@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"cbfa107604f4cbfaf02bd633c1faa6ecb90c6dd7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cbfa107604f4cbfaf02bd633c1faa6ecb90c6dd7" Improve seq documentation; part of trac issue #9390 Summary: Signed-off-by: Michael Snoyman Test Plan: Review documentation change Reviewers: simonpj, austin Reviewed By: austin Subscribers: phaskell, hvr, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D136 GHC Trac Issues: #9390 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:54:44 -0000 Subject: [GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled In-Reply-To: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> References: <044.0c8606ec248a61b17a138fdb6cbb90d5@haskell.org> Message-ID: <059.203f9de4ef54f069cd815c5001ddacc0@haskell.org> #9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: pthread staticlib Operating System: MacOS X | threaded Type of failure: Compile- | Architecture: x86 time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D120 | -------------------------------------+------------------------------------- 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 Sun Aug 10 20:55:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:55:12 -0000 Subject: [GHC] #7919: Heap corruption (segfault) from large 'let' expression In-Reply-To: <045.3707d678a38441ef54b667e63e238d84@haskell.org> References: <045.3707d678a38441ef54b667e63e238d84@haskell.org> Message-ID: <060.4f7f4659d20d9b77969a307b98665117@haskell.org> #7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The test case T7919 crashes for me some of the time when run with WAY=threaded2 in a validate tree. Haven't looked into exactly how that relates to this ticket, but thought I would report it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 20:58:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 20:58:42 -0000 Subject: [GHC] #7775: Mark intentionally omitted type class instances In-Reply-To: <046.4ccee8d752caf5aeb2798444e4f16594@haskell.org> References: <046.4ccee8d752caf5aeb2798444e4f16594@haskell.org> Message-ID: <061.0248f2924bdb7fd111c900fd9442bb8f@haskell.org> #7775: Mark intentionally omitted type class instances -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Keywords: instance warning (Type checker) | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Lemming): Maybe it can still become true via #9334. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 21:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 21:00:42 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.7ca509477cc8c9bc82c1b430f85a8a3f@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) | 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 Lemming): * cc: ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 23:08:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 23:08:47 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend Message-ID: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 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: -------------------------------------+------------------------------------- There are a number of arithmetic operations that have native implementations on x86 but use the generic fallback on LLVM. Implementing these with LLVM intrinsics could improve small Integer performance on ARM substantially! {{{ MO_Add2 @llvm.uadd.with.overflow.* MO_AddIntC @llvm.sadd.with.overflow.* MO_SubIntC @llvm.ssub.with.overflow.* MO_U_Mul2 mul i64/i128? MO_U_QuotRem2 udiv i64/i128? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 23:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 23:09:52 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.dd5fc098aa2a8dbe37e640bd5a7a824e@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) | 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 AntC): Replying to [comment:4 diatchki]: > 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 suspect they're rare, but yes they are problematic. Can't you always resolve this today with an instance at the intersect? {{{ instance C Int Int where ... instance C Int a where ... instance C a Int where ... }}} (The `where`'s body for `C Int Int` would be the same as `C Int a` to match Ivor's example.) Probably for this to work all three instances must be in the same module. The main awkwardness is that GHC still sees the partially overlapping two instances and gets upset (wants `XIncoherentInstances`). If only it could realise there is no incoherence! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 23:14:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 23:14:27 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.cd4c6929a49f892c4040950c448a4367@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (LLVM) | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I probably won't get around to this myself in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 23:34:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 23:34:40 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.07e6026847e0fcd1b9124ddf62ceb10f@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) | 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 aavogt): Replying to [comment:6 diatchki]: > 2. "Fails instances", which are of the form `instance Num Char fails`; they enable programmers to state explicitly that an instance should never exits. Interestingly, I just found a very related ticket asking for the same sort of thing (#7775). In some sense this can already be done: {{{ class FailHasNoInstances a => Fail a class FailHasNoInstances a -- not exported to ban Fail instances instance Fail "Char may not have a Num instance" => Num Char main = print $ '1' + '1' {- has a compile failure: No instance for (Fail "Char may not have a Num instance") arising from a use of ?+? In the second argument of ?($)?, namely ?'1' + '1'? In the expression: print $ '1' + '1' In an equation for ?main?: main = print $ '1' + '1' -} }}} > 3. "Using instance contexts when selecting instances (aka backtracking)": currently, if the head of an instance matches a goal, GHC commits to it and then fails if it encounters an error; an alternative design would be to back-track and try a different option (e.g., next member of an instance group, or a more general matching instance). Perhaps with a class like {{{ class HasInstance (cxt :: Constraint) (b :: Bool) | cxt -> b }}} you can encode backtracking without too much pain, and the meaning of existing programs does not change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 10 23:55:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Aug 2014 23:55:41 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.967c347a4cf31e03604e62279eb13552@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: facundo.dominguez@? (removed) * cc: facundo.dominguez (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 00:43:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 00:43:04 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.7e173d69250425eeef4024e9e38f5da3@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: (LLVM) | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): In fact, with these changes it may end up making sense to build integer- gmp with LLVM anywhere we can. (At least if split-objs worked with LLVM: #8300.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 01:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 01:01:45 -0000 Subject: [GHC] #9431: integer-gmp small Integer multiplication does two multiplications on x86 Message-ID: <047.affdf8ab1c2013e525e334d331ebc594@haskell.org> #9431: integer-gmp small Integer multiplication does two multiplications on x86 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- `timesInteger` begins thusly: {{{ timesInteger :: Integer -> Integer -> Integer timesInteger (S# i) (S# j) = if isTrue# (mulIntMayOflo# i j ==# 0#) then S# (i *# j) else -- ... }}} The x86 backend implements `mulIntMayOflo#` as a (word, word) -> double word multiplication, followed by bit manipulation to test for overflow of the low word. Then, if there was no overflow, on the next line we multiply the operands again. We should be able to do better here. We need a new primop that combines `mulIntMayOflo#` with the actual multiplication result, at least in the non-overflow case (though with some more work we might be able to turn the double word result directly into a large Integer), and then we need to update `timesInteger` to use it. The LLVM backend probably has the same behavior, though it might be smart enough to notice that the multiplication is repeated; I haven't checked its assembly output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 01:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 01:53:29 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.648771b6b372b9186e190ebb0a5775c7@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 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: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): While it was already moved up to 7.10, I'd like to mention that I just hit it in 7.8.3 so it has not gone away while noone was looking. Specifically I hit this with ?sizes-2.3.1.1? package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 02:14:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 02:14:39 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.0325e85e48ce658bca6fe9bd5438e765@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.2.1 Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => wontfix Comment: This bug is obsolete now, considering we've removed external core completely in HEAD. Nobody had maintained it for years, so it was pretty bitrotten. As a result I'm closing this as WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 02:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 02:15:07 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.7ec61768df1359b5b46fd8e8662ec321@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 03:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 03:52: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.ce4bc5a5dcd2610dd1e21f17e637c2ee@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): Actually I prefer this one, since I can read x86 assembly better than ARM assembly :) The TBAA patch had the expected effect on the .ll file. But LLVM 3.0 still decided to carefully save the input value across the function call so that it can erroneously return it as the result (esi). {{{ 00000748 83ec1c sub esp, 0x1c 0000074b 8d45fc lea eax, [ebp-4] 0000074e 3bab1c030000 cmp ebp, [ebx+0x31c] 00000754 7235 jc 0x78b 00000756 f30f104500 movss xmm0, [ebp] 0000075b f30f11442418 movss [esp+0x18], xmm0 00000761 f30f11442408 movss [esp+0x8], xmm0 00000767 89442404 mov [esp+0x4], eax 0000076b 892c24 mov [esp], ebp 0000076e e815faffff call __decodeFloat_Int 00000773 8b45fc mov eax, [ebp-4] 00000776 894500 mov [ebp], eax 00000779 8b4504 mov eax, [ebp+0x4] 0000077c f30f10442418 movss xmm0, [esp+0x18] 00000782 660f7ec6 movd esi, xmm0 00000786 83c41c add esp, 0x1c 00000789 ffe0 jmp eax }}} I think this is just a bug in LLVM 3.0, particularly as you say LLVM 3.4 has the expected behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 07:22:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 07:22:17 -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.2edbe28d095a4c042b0aef569ffec79b@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed by Phab:D99 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 07:25:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 07:25:33 -0000 Subject: [GHC] #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit-yields mode In-Reply-To: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> References: <045.751ae57c6da2ecc241cf2aa97851b1dc@haskell.org> Message-ID: <060.46773332e63f9dc1c268e7c938d33c28@haskell.org> #9425: ghc-HEAD (only in -O -fllvm aka 'optllvm') prunes yield in -fno-omit- yields mode -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | 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 simonmar): * status: new => closed * resolution: => duplicate Comment: dup of #7297 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 08:00:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 08:00:31 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted Message-ID: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hello! The reason behind using `IncoherentInstances`is that we want GHC to commit to a specific instance even if after instantiation of some variables, other instance could be more specific (http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/type-class- extensions.html). There is one problem though. Lets consider following example (which could not make much sense, but shows the problem well): {{{#!haskell {-# OPTIONS_GHC -fno-warn-missing-methods #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE IncoherentInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Typeable -------------------------------------------------------------------------------- -- Type classes -------------------------------------------------------------------------------- class InferType a where inferType :: Proxy a -> Proxy a inferType = undefined -------------------------------------------------------------------------------- -- Proxy datatypes -------------------------------------------------------------------------------- data Id0 = Id0 deriving (Show, Typeable) data Id1 t1 = Id1 deriving (Show, Typeable) data Id2 t1 t2 = Id2 deriving (Show, Typeable) data Id3 t1 t2 t3 = Id3 deriving (Show, Typeable) data Id4 t1 t2 t3 t4 = Id4 deriving (Show, Typeable) data Id5 t1 t2 t3 t4 t5 = Id5 deriving (Show, Typeable) -------------------------------------------------------------------------------- -- Instances -------------------------------------------------------------------------------- instance InferType Int instance (InferType m, InferType a) => InferType (m a) instance (a~Id0) => InferType (a :: *) instance (a~Id1) => InferType (a :: * -> *) instance (a~Id2) => InferType (a :: * -> * -> *) -------------------------------------------------------------------------------- -- Tests -------------------------------------------------------------------------------- toProxy :: a -> Proxy a toProxy _ = Proxy --inferTypeBase :: a -> Proxy a inferTypeBase a = inferType $ toProxy a instance InferType Foo1 instance InferType Foo2 tm _ = 5 data Foo1 a = Foo1 a deriving (Show, Typeable) data Foo2 a b = Foo2 a b deriving (Show, Typeable) instance Monad Id1 -- dummy instances just for tests instance Num Id0 main = do print $ typeOf $ inferType $ toProxy $ (return (5)) print $ typeOf $ inferType $ toProxy $ (5) print $ typeOf $ inferType $ toProxy $ (Foo1 (return 5)) print $ typeOf $ inferType $ toProxy $ (Foo2 (return 5) (return 5)) print "hello" ---- OUTPUT: -- Proxy (Id1 Id0) -- Proxy Id0 -- Proxy (Foo1 (Id1 Id0)) -- Proxy (Foo2 (Id1 Id0) (Id1 Id0)) -- "hello" }}} The idea is very simple - replace all unknown type variables with known ones. It works great, but the problem appears with the function `inferTypeBase`. It should have type of `a -> Proxy a`, but GHC claims it has got `Id0 -> Proxy Id0`. It is of course caused by enabled `-XIncoherentInstances` flag, but I think GHC should be more liberal here. If it really cannot pick any instance (causing an error using only `OverlappingInstances`), the `IncoherentInstances` should allow it to pick matching one even if more specific could be available after instantianization. But If no error would occur while using `OverlappingInstances`, `IncoherentInstances` should not affect the way it resolves the instances. I think this would make `IncoherentInstances` much more useful than now. Maybe it would be good to just add some options to the flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 08:40:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 08:40:19 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.d6b4859de59b6dcc8db8231056efb765@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------- Reporter: pumpkin | 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: Phab:D137 | -------------------------------------+------------------------------------- Comment (by simonmar): I've accepted @rwbarton's diff. > Surely it'd be better for some earlier phase to optimise (plusWord# x (-1)) to (minusWord# x 1) The problem is that this would only catch instructions that arise from those particular primops, not any other instructions. Add instructions arise for lots of reasons, even during native code generation itself. The reason the peephole is done very late is * We don't need explicit inc/dec instructions in the data type * We catch all the opportunities. Anything else would run the risk of any subsequent optimisation passes leaving opportunities behind. A smart constructor would work but also runs the risk that you might forget to use it somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 10:37:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 10:37:30 -0000 Subject: [GHC] #4479: Implement Dot as Postfix Function Apply (was: Add Type Directed Name Resolution) In-Reply-To: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> References: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> Message-ID: <059.35e46e58b3c31b3175d158607e55bea9@haskell.org> #4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.5 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: | -------------------------------------+------------------------------------- Description changed by gidyn: Old description: > A request to implement [http://hackage.haskell.org/trac/haskell- > prime/wiki/TypeDirectedNameResolution type-directed name resolution], as > [http://hackage.haskell.org/trac/haskell-prime/ticket/129 proposed] for > Haskell'. New description: A request to implement [https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix Dot as Postfix Function Apply]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 10:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 10:54:49 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.96388648974dc8f411a2ad917bb2d9bf@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: high | 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 danilo2): Maybe we should treat it as a bug? I've got here a small example showing that it really breaks how `OverlappingInstances` are working: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE IncoherentInstances #-} -- the flag is niot needed by the example module Main where import Data.Typeable class CTest a b | a -> b where cTest :: a -> b cTest = undefined -- this example is choosen even if more specific is available! instance out~a => CTest a out where cTest = id instance CTest Int String where cTest _ = "test" main = do print $ typeOf $ cTest (5::Int) }}} The instance `CTest a out` even if more specific (`CTest Int String`) is in scope, which just breaks how `OverlappingInstances` work. If we disable the `IncoherentInstances` flag, the right one is selected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 11:07:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 11:07:36 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.3d64fd729ea2c55f563736b5a42da5b4@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (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: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr Comment: I'm now actively working on this one. And I've already got semi-working code that I'll submit to Phab soon (some pre-requisite code is already submitted as Phab:D141) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 11:56:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 11:56:25 -0000 Subject: [GHC] #9431: integer-gmp small Integer multiplication does two multiplications on x86 In-Reply-To: <047.affdf8ab1c2013e525e334d331ebc594@haskell.org> References: <047.affdf8ab1c2013e525e334d331ebc594@haskell.org> Message-ID: <062.33410fc184f0a29fd8396ae4d449301a@haskell.org> #9431: integer-gmp small Integer multiplication does two multiplications on x86 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 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 hvr): It'd be interesting to know *why* `mulIntMayOflo#` was introduced instead of a version that'd output the non-overflowing result as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 12:24:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 12:24:44 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.831fc841a3df7cb23a90df36b0945cac@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | 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: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by danilo2): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 13:08:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 13:08:36 -0000 Subject: [GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' In-Reply-To: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> References: <045.4a6b72a25dd245d66de01ff299d3a844@haskell.org> Message-ID: <060.8a52ab8dfe443a74a8155e5c137fc4b3@haskell.org> #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | 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 slyfox): Suspicious observation: As in original test case {{{!#hs instance {-# OVERLAPS #-} (HTrue ~ b) => TypeEq x x b instance {-# OVERLAPS #-} (HTrue ~ b) => TypeEq x x b instance {-# OVERLAPS #-} (HFalse ~ b) => TypeEq x y b }}} leads to error {{{ *** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 912 }}} (the name failing invariant is '$fTypeEqxxb') If we slightly change free variables: {{{!#hs instance {-# OVERLAPS #-} (HTrue ~ b) => TypeEq x x b instance {-# OVERLAPS #-} (HTrue ~ b) => TypeEq y y b -- changed 'x' to 'y' instance {-# OVERLAPS #-} (HFalse ~ b) => TypeEq x y b }}} there is no assert anymore: {{{ Prelude> :script z.script WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqyyb WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqxyb WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqyyb WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqxyb }}} Looks like some generated names are not unique emough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 13:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 13:57:45 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.7365e6a33927f11862f70c761a440c11@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------- Reporter: pumpkin | 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: Phab:D137 | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"71bd4e310793b9225767b66f3aa758156816632e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="71bd4e310793b9225767b66f3aa758156816632e" x86: Always generate add instruction in MO_Add2 (#9013) Test Plan: - ran validate - ran T9013 test with all ways - ran CarryOverflow test with all ways, for good measure Reviewers: austin, simonmar Reviewed By: simonmar Differential Revision: https://phabricator.haskell.org/D137 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 13:59:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 13:59:05 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.c29afa6ee4d786aabf5feca813187c86@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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: Phab:D137 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 14:44:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 14:44:42 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.ee54d20c8b01b46afc77abba73fdb099@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: simonmar AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * differential: => Phab:D129 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 15:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 15:39:12 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.d21f5086ed6434e66335f03b258fcbe4@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Works for me. A clang CPP issue perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 16:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 16:10:05 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.976d4acd370e2baacd55d6d5807b1c63@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | 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: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! The reason behind using `IncoherentInstances`is that we want GHC > to commit to a specific instance even if after instantiation of some > variables, other instance could be more specific > (http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/type-class- > extensions.html). There is one problem though. Lets consider following > example (which could not make much sense, but shows the problem well): > > {{{#!haskell > {-# OPTIONS_GHC -fno-warn-missing-methods #-} > > {-# LANGUAGE NoMonomorphismRestriction #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE DeriveDataTypeable #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE IncoherentInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > > module Main where > > import Data.Typeable > > -------------------------------------------------------------------------------- > -- Type classes > -------------------------------------------------------------------------------- > > class InferType a where > inferType :: Proxy a -> Proxy a > inferType = undefined > > -------------------------------------------------------------------------------- > -- Proxy datatypes > -------------------------------------------------------------------------------- > > data Id0 = Id0 deriving (Show, Typeable) > data Id1 t1 = Id1 deriving (Show, Typeable) > data Id2 t1 t2 = Id2 deriving (Show, Typeable) > data Id3 t1 t2 t3 = Id3 deriving (Show, Typeable) > data Id4 t1 t2 t3 t4 = Id4 deriving (Show, Typeable) > data Id5 t1 t2 t3 t4 t5 = Id5 deriving (Show, Typeable) > > -------------------------------------------------------------------------------- > -- Instances > -------------------------------------------------------------------------------- > > instance InferType Int > > instance (InferType m, InferType a) => InferType (m a) > instance (a~Id0) => InferType (a :: *) > instance (a~Id1) => InferType (a :: * -> *) > instance (a~Id2) => InferType (a :: * -> * -> *) > > -------------------------------------------------------------------------------- > -- Tests > -------------------------------------------------------------------------------- > toProxy :: a -> Proxy a > toProxy _ = Proxy > > --inferTypeBase :: a -> Proxy a > inferTypeBase a = inferType $ toProxy a > > instance InferType Foo1 > instance InferType Foo2 > > tm _ = 5 > > data Foo1 a = Foo1 a deriving (Show, Typeable) > data Foo2 a b = Foo2 a b deriving (Show, Typeable) > > instance Monad Id1 -- dummy instances just for tests > instance Num Id0 > > main = do > print $ typeOf $ inferType $ toProxy $ (return (5)) > print $ typeOf $ inferType $ toProxy $ (5) > print $ typeOf $ inferType $ toProxy $ (Foo1 (return 5)) > print $ typeOf $ inferType $ toProxy $ (Foo2 (return 5) (return 5)) > > print "hello" > > ---- OUTPUT: > -- Proxy (Id1 Id0) > -- Proxy Id0 > -- Proxy (Foo1 (Id1 Id0)) > -- Proxy (Foo2 (Id1 Id0) (Id1 Id0)) > -- "hello" > > }}} > > The idea is very simple - replace all unknown type variables with known > ones. It works great, but the problem appears with the function > `inferTypeBase`. It should have type of `a -> Proxy a`, but GHC claims it > has got `Id0 -> Proxy Id0`. It is of course caused by enabled > `-XIncoherentInstances` flag, but I think GHC should be more liberal > here. > If it really cannot pick any instance (causing an error using only > `OverlappingInstances`), the `IncoherentInstances` should allow it to > pick matching one even if more specific could be available after > instantianization. But If no error would occur while using > `OverlappingInstances`, `IncoherentInstances` should not affect the way > it resolves the instances. I think this would make `IncoherentInstances` > much more useful than now. Maybe it would be good to just add some > options to the flag? New description: Hello! The reason behind using `IncoherentInstances`is that we want GHC to commit to a specific instance even if after instantiation of some variables, other instance could be more specific (http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/type-class- extensions.html). There is one problem though. Lets consider following example (which could not make much sense, but shows the problem well): {{{#!haskell {-# OPTIONS_GHC -fno-warn-missing-methods #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE IncoherentInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Typeable -------------------------------------------------------------------------------- -- Type classes -------------------------------------------------------------------------------- class InferType a where inferType :: Proxy a -> Proxy a inferType = undefined -------------------------------------------------------------------------------- -- Proxy datatypes -------------------------------------------------------------------------------- data Id0 = Id0 deriving (Show, Typeable) data Id1 t1 = Id1 deriving (Show, Typeable) data Id2 t1 t2 = Id2 deriving (Show, Typeable) data Id3 t1 t2 t3 = Id3 deriving (Show, Typeable) data Id4 t1 t2 t3 t4 = Id4 deriving (Show, Typeable) data Id5 t1 t2 t3 t4 t5 = Id5 deriving (Show, Typeable) -------------------------------------------------------------------------------- -- Instances -------------------------------------------------------------------------------- instance InferType Int instance (InferType m, InferType a) => InferType (m a) instance (a~Id0) => InferType (a :: *) instance (a~Id1) => InferType (a :: * -> *) instance (a~Id2) => InferType (a :: * -> * -> *) -------------------------------------------------------------------------------- -- Tests -------------------------------------------------------------------------------- toProxy :: a -> Proxy a toProxy _ = Proxy --inferTypeBase :: a -> Proxy a inferTypeBase a = inferType $ toProxy a instance InferType Foo1 instance InferType Foo2 tm _ = 5 data Foo1 a = Foo1 a deriving (Show, Typeable) data Foo2 a b = Foo2 a b deriving (Show, Typeable) instance Monad Id1 -- dummy instances just for tests instance Num Id0 main = do print $ typeOf $ inferType $ toProxy $ (return (5)) print $ typeOf $ inferType $ toProxy $ (5) print $ typeOf $ inferType $ toProxy $ (Foo1 (return 5)) print $ typeOf $ inferType $ toProxy $ (Foo2 (return 5) (return 5)) print "hello" ---- OUTPUT: -- Proxy (Id1 Id0) -- Proxy Id0 -- Proxy (Foo1 (Id1 Id0)) -- Proxy (Foo2 (Id1 Id0) (Id1 Id0)) -- "hello" }}} The idea is very simple - replace all unknown type variables with known ones. It works great, but the problem appears with the function `inferTypeBase`. It should have type of `a -> Proxy a`, but GHC claims it has got `Id0 -> Proxy Id0`. It is of course caused by enabled `-XIncoherentInstances` flag, but I think GHC should be more liberal here. If it really cannot pick any instance (causing an error using only `OverlappingInstances`), the `IncoherentInstances` should allow it to pick matching one even if more specific could be available after instantianization. But If no error would occur while using `OverlappingInstances`, `IncoherentInstances` should not affect the way it resolves the instances. I think this would make `IncoherentInstances` much more useful than now. Maybe it would be good to just add some options to the flag? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 18:30:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 18:30:46 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable Message-ID: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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: -------------------------------------+------------------------------------- I was playing around with the following code, which tries to map a type family over a type (something I thought would not be allowed): {{{#!hs {-# LANGUAGE TypeFamilies , KindSignatures #-} type family Id x :: * type instance Id a = a type family Map (f :: * -> *) x :: * type instance Map f [a] = [f a] x :: Map Id [Bool] x = [] }}} Both GHC 7.8.3 and the current HEAD (7.9.20140811) accept this program! However, changing the definition of `x` to `[True]` gives an error: {{{ Couldn't match type ?Id Bool? with ?Bool? Expected type: Map Id [Bool] Actual type: [Bool] In the expression: [True] In an equation for ?x?: x = [True] }}} If I define `y :: Id Bool` with value `True` (which works fine) and define `x = [y]`, I even get this error: {{{ Couldn't match type ?Bool? with ?Id Bool? Expected type: Id Bool Actual type: Id Bool In the expression: y In the expression: [y] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 19:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 19:00:38 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.fcbd13d0eef3daf39683db39e4f17ef7@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.1 (other) | 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 rwbarton): As I see it "representational" has to do with the representation of Haskell values as closures (usually on the heap). That's different from the representation of the "underlying value" in an unboxed or storable array. For example, if I needed to process packed arrays of 24-bit integers, I might create a newtype of Int and write a Storable instance for it with `sizeOf _ = 3`. (Admittedly this is a somewhat contrived scenario.) The same considerations also apply to `Ptr`. (Indeed, a storable array is little more than a `Ptr` under the hood.) But `Ptr` is an inherently unsafe/unmanaged sort of thing. If you want to know how many items' worth of space is allocated in an area pointed to by a `Ptr`, you have to keep track of it yourself. Unboxed/storable arrays are supposed to be a safe abstraction on top of raw memory areas. That's why I think it's reasonable to have different defaults between unboxed/storable arrays and `Ptr`s. (And it is in some sense a matter of defaults, since there is still `unsafeCoerce` when you happen to know that the memory layouts match up properly.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 19:31:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 19:31:18 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.32f38e36d45e9210bc8a80f34cb3a7f3@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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 rwbarton): * milestone: => 7.10.1 Comment: Whatever we decide to do, we may as well decide by 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 20:45:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 20:45:00 -0000 Subject: [GHC] #7297: LLVM incorrectly hoisting loads In-Reply-To: <045.bd816ad08f5119bccde9f8a70a030128@haskell.org> References: <045.bd816ad08f5119bccde9f8a70a030128@haskell.org> Message-ID: <060.afa1b9aac57eb88684b910cd5c286cbe@haskell.org> #7297: LLVM incorrectly hoisting loads -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | 367_letnoescape | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 21:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 21:11:58 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.1d17aada73aa52ea9ad7943c7245a7a4@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Possibly. Not sure how to test whether it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 21:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 21:43:20 -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.75293c8028b62c700b07088e46762e29@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.3 (LLVM) | Keywords: fannkuch-redux Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: #5567 result at runtime | Test Case: fannkuch- | redux | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * failure: Runtime performance bug => Incorrect result at runtime * component: NoFib benchmark suite => Compiler (LLVM) * os: MacOS X => Unknown/Multiple * related: => #5567 Comment: I can reproduce this with LLVM 3.3 on Linux x86_64. This one is a TBAA issue. The infinite loop goes away with `-fno-llvm-tbaa` or with this patch applied (from #9125): {{{ diff --git a/compiler/llvmGen/LlvmCodeGen/Regs.hs b/compiler/llvmGen/LlvmCodeGen/Regs.hs index 0048659..d837d13 100644 --- a/compiler/llvmGen/LlvmCodeGen/Regs.hs +++ b/compiler/llvmGen/LlvmCodeGen/Regs.hs @@ -101,11 +101,6 @@ stgTBAA , (heapN, fsLit "heap", Just topN) , (rxN, fsLit "rx", Just heapN) , (baseN, fsLit "base", Just topN) - -- FIX: Not 100% sure about 'others' place. Might need to be under 'heap'. - -- OR I think the big thing is Sp is never aliased, so might want - -- to change the hieracy to have Sp on its own branch that is never - -- aliased (e.g never use top as a TBAA node). - , (otherN, fsLit "other", Just topN) ] -- | Id values @@ -115,7 +110,7 @@ stackN = getUnique (fsLit "LlvmCodeGen.Regs.stackN") heapN = getUnique (fsLit "LlvmCodeGen.Regs.heapN") rxN = getUnique (fsLit "LlvmCodeGen.Regs.rxN") baseN = getUnique (fsLit "LlvmCodeGen.Regs.baseN") -otherN = getUnique (fsLit "LlvmCodeGen.Regs.otherN") +otherN = topN -- | The TBAA metadata identifier tbaa :: LMString }}} The issue is Cmm code that looks like this: {{{ /* let go !acc = do k <- peekElemOff xs 0 if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1) */ c7b3: _s6xW::I64 = I64[Sp + 8]; _s6yp::I64 = %MO_UU_Conv_W8_W64(I8[_s6xW::I64]); // read from xs via _s6xW: TBAA "other" if (_s6yp::I64 != 0) goto c7ca; else goto c7cb; c7ca: I64[Sp - 8] = block_c7bd_info; R3 = _s6xW::I64 + _s6yp::I64; R2 = _s6xW::I64; Sp = Sp - 8; call $wa1_r6tm_info(R3, R2) args: 8, res: 8, upd: 8; ... /* flop k xs = flopp xs (xs `advancePtr` k) where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j) swap i j = do a <- peek i b <- peek j poke j a poke i b */ $wa1_r6tm_entry() // [R3, R2] ... {offset c6Wl: if (R2 < R3) goto c6Ws; else goto c6Wt; c6Ws: _s6uQ::I64 = %MO_UU_Conv_W8_W64(I8[R3]); I8[R3] = I8[R2]; // read from xs via R2: TBAA "rx" I8[R2] = %MO_UU_Conv_W64_W8(_s6uQ::I64); R3 = R3 - 1; R2 = R2 + 1; call $wa1_r6tm_info(R3, R2) args: 8, res: 0, upd: 8; }}} "rx" and "other" are incomparable in our TBAA tree. Apparently LLVM treats this as undefined behavior and, in this case, emits an infinite loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 21:48:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 21:48:46 -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.466b4eaff08fff722c23b8ff6863ea29@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. Indeed that object file looks much more sensible. Would you mind trying one more thing with LLVM 3.0 (with either the original or patched source tree)? Could you find the BuildFlavour stanza you are using in `mk/build.mk` (or just globally replace all of them if not sure) and change all occurrences of `-fllvm` to `-fllvm -fno-llvm- tbaa`? Curious if that would fix the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 22:33:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 22:33:52 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.1b99ebdc236fe3b9e7f95a4c307d8d8c@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh yes, I see `clang -E -traditional` doesn't expand the `printTest` macro because of the space after the macro name. We could fix the test to be clang-compatible of course, but I don't know whether that is the right thing to do. Perhaps the fact that ghci has invoked clang at all indicates that something has already gone wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 22:58:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 22:58:50 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.76f423c1cb124b42ccb54bbdafaba94e@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Don't follow you. The test explicitly invokes CPP (both on the command line and with a pragma). If you clang -P - < enum0x.hs the macro printTest seems to be expanded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 11 23:08:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Aug 2014 23:08:16 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.3ec798b87eb5c5a40703f3496e90e0ac@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): But not with `-traditional`. Try `ghci -v -cpp enum01.hs`; how does `ghci` invoke the C pre-processor (should follow the line `*** C pre- processor:`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 01:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 01:51:24 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.f8bc218cb9bffef1f5d84af714290ae8@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): While #9380 is indeed fixed by making `Any` a type family, an alternative fix would be to change the pattern-match pruner to be `Any`-aware. I say this because there is something sensible about allowing `Any` to be a datatype in any open kind. I haven't quite thought it all through, but somehow that might make sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 01:55:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 01:55:04 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.758f493843033d44e110a4d08ce62e3b@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): This is subtler than I thought. The email trail linked in the original description suggests that TauTvs can be unified with forall-types, but cannot be solved to become a forall-type. This is true, but only partially: the forall-type in question must be devoid of any type families, *and* the TauTv must be of kind `OpenKind`. I have implemented, in a branch [https://github.com/goldfirere/ghc/tree /removed-tcInfExpr here], a version of GHC missing `tcInfExpr`, the under- implemented version of `tcExpr` that infers a type instead of checking it. The problem is that, in that branch, the following fails: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} module Rank where type family ListTF x where ListTF x = [x] bar :: (forall x. ListTF x -> Int) -> () bar _ = () foo = bar $ length }}} For the curious, the error message is {{{ Couldn't match type ?[a0] -> Int? with ?forall x. ListTF x -> Int? Expected type: ([a0] -> Int) -> () Actual type: (forall x. ListTF x -> Int) -> () In the expression: bar In the expression: bar $ length }}} So, the "obvious" fix to the original bug doesn't work. The problem outlined in this comment (interaction between the mention of type families and inference) can be observed in 7.8, with the following rather contrived construction: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} module Rank where type family ListTF x where ListTF x = [x] bar :: (forall x. ListTF x -> Int) -> () bar _ = () myconst :: ((forall r. ListTF r -> Int) -> ()) -> x -> (forall r. ListTF r -> Int) -> () myconst x _ = x foo = (bar `myconst` ()) $ length }}} If, in the last line, `myconst` is applied prefix instead of infix, the module compiles. It seems the solution here is to fully implement `tcInfExpr`, instead of eliminate it, so that `tcInfExpr` is aware of infix operators, sections, and probably other expression forms. With that done, the problems outlined here should go away. But, given the smelliness around all of this, I think it's best to let The Expert (who is on holiday, I understand) weigh in before proceeding. It's also worth noting that the problems I've encountered to post this ticket have all been "white box" -- I detected the problem reading GHC source code, not by stumbling into it. It's quite possible that this infelicity has never triggered a problem in the wild. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 02:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 02:45:05 -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.c39893d4b868342a7005bc4fac064e16@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This happened to me too trying to build the ghc-7.8 branch with "perf- llvm". Same closure type number, even. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 02:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 02:56:29 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.6d9c970d8cee4c127eaefc7ec49289a1@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Is something like Any needed, or just a way of reifying that polymorphic type? (i'm trying to understand what the fundamental problem is vs whats currently needed to solve the problem) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 05:01:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 05:01:26 -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.8b65f260851cd3d27f8f5bdfd32e3d94@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm having a strong sense of deja vu here. {{{ (gdb) print p->payload[0] $19 = (struct StgClosure_ *) 0x7fc6475e2861 (gdb) print *((struct StgClosure_ *)0x7fc6475e2860) $20 = {header = {info = 0x403310 }, payload = 0x7fc6475e2868 } }}} Note the info pointer pointing into the PLT. That's not good, there is no info table before the PLT entry! I seem to recall debugging the same issue and the problem being that LLVM was emitting `@function`s instead of `@objects`. Somehow the LLVM mangler isn't doing its job. But I don't understand why not. It seems to operate properly when I run it manually. Perhaps I should try building the stage1 compiler with the NCG and then the RTS and libraries with `-fllvm`, in case there is some pernicious bug in the LLVM backend affecting the LLVM mangler... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 05:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 05:01:47 -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.c4222695fc255c9f9f96afaf563b5c7b@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9268 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by rwbarton): * related: => #9268 Comment: Maybe the same issue as #9268. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 07:51:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 07:51:20 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.bda974f12679dd9281dfe7bccd1b8d9d@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (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: Phab:D144 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D144 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 08:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 08:19:19 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse Message-ID: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 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: -------------------------------------+------------------------------------- As Edward Kmett speculated could be the case a couple months ago, Joachim Breitner's call arity analysis makes the Prelude version of `reverse` better than GHC's version. It's less clear to me whether it's beneficial to wrap it in `build`, but I think the answer is ''probably'' yes, based on the fact that doing so turns `foldr c n $ reverse xs` into `foldl (flip c) n xs`. {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} This simplifies to {{{#!hs Rec { poly_go_r2uL poly_go_r2uL = \ @ a_a2nn ds_a2xO eta_Xh -> case ds_a2xO of _ { [] -> eta_Xh; : y_a2xT ys_a2xU -> poly_go_r2uL ys_a2xU (: y_a2xT eta_Xh) } end Rec } reverse reverse = \ @ a_a2nn eta_B1 -> poly_go_r2uL eta_B1 ([]) }}} which looks about the same as the current version in GHC.List. Behold the beauty when it is applied to an unfold (with a fusion-friendly version of `unfoldr`): {{{#!hs testReverseUnfoldr f q0 = reverse (unfoldr f q0) }}} simplifies to {{{#!hs testReverseUnfoldr testReverseUnfoldr = \ @ a_a2w3 @ b_a2w4 f_a2mn q0_a2mo -> letrec { go_a1QX go_a1QX = \ b1_a1Hy eta_B1 -> case f_a2mn b1_a1Hy of _ { Nothing -> eta_B1; Just ds_d2d8 -> case ds_d2d8 of _ { (a1_a1Hz, new_b_a1HA) -> go_a1QX new_b_a1HA (: a1_a1Hz eta_B1) } }; } in go_a1QX q0_a2mo ([]) }}} This looks exactly like a hand-written `unfoldl`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 10:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 10:09:52 -0000 Subject: [GHC] #9435: Steroids: Distorting The Worlds Of Muscle And Fitness Message-ID: <048.7e2d08eb69a15b8d7a823792e8ca470e@haskell.org> #9435: Steroids: Distorting The Worlds Of Muscle And Fitness -------------------------------------+------------------------------------- Reporter: deankai74 | 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: -------------------------------------+------------------------------------- Nix has been many distortive to yobbo building collection than the low saliency prevalence of endocrine use. What else can justify the vast quantity of lousy [http://muscleshealthpro.com/testinate-250-review/ Testinate 250] and steady discarded upbringing techniques for fresh trainers that human become the current wiseness in the musclebuilding industry? There's an ongoing discord between imaginativeness and actuality in what constitutes an efficacious fresh musculus gaining turn. That disagreement is most belike referable to the overt yet often unaddressed oppositeness between the physiology of a hormone mortal and that of a non- user.This opposition is the exclusive statement for exercising's longtime miring in misinformation; a muddling that's ofttimes resulted in nearly humorously incompatible ecommendations and advice.Here's a position of fantastical observations I've prefabricated over the life that I imagine can be linked, either flat or indirectly, to many of that misinformation:'''Testinate 250''' I attended a musclebuilding seminar put on by one of the top Mr. Champaign contenders of the instant. When asked by an conference member active a specialized workout package, the pro human answered that the workout schedule in ponder would be rubbishy for putting on ruffian body. Within a month, I saw that photographic workout/recovery schedule state recommended in a bodybuilding publisher by the then-Mr. Champaign.In the '90s, that comparable had a farewell workout television syllabus for mainstream suitableness. During an film, I heard him mouth to Geraldo Riviera nigh the evils of anabolics code-word for steroids. He was ostensibly disagreeable to dissuade youngsters from using them. Yet he admitted within different mediums that he misused them regularly of row he victimized them; he was a pro mortal http://muscleshealthpro.com/testinate-250-review/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 11:10:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 11:10:09 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.dd344ac04e2cd0713b202718f71cdf15@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): Making pattern-matching `Any`-aware makes sense to me. Again, I'm not qualified to understand what the best way forward is here. But to answer carter's question, ultimately for the purposes of `rank1dynamic` (and by extension Cloud Haskell), what we need is way of reifying more polymorphic types than we currently can. Introducing some kind of `PolyTypeable` mechanism could certainly bypass the question at hand. Really not sure how such an extension would work though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 11:37:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 11:37:29 -0000 Subject: [GHC] #9436: Mistakes Leading To An Eventual Burnout Message-ID: <048.8c6fba73580e703a75e1fe18a66a06b8@haskell.org> #9436: Mistakes Leading To An Eventual Burnout -------------------------------------+------------------------------------- Reporter: deankai74 | 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: -------------------------------------+------------------------------------- To understand how to deal with a burnout once its time is nigh, going through the most probable mistakes and reasons as to why a burnout would occur is a sure [http://muscleshealthpro.com/testinate-250-review/ Testinate 250] way. As thin or skinny as one might be, bulking up to around 215 pounds is the first mistake. This is able to make one look like a fattened rugby player as compared to a bodybuilder. One should always be honest to himself or herself if success will be enjoyed.It is paramount that a bodybuilder realizes that some pounds must be tossed out so that they could be in top shape competitive physique. But a mistake would arise if one would be doing the right thing if he/she trains using light as well as medium weights while at the same time increasing reps.This fact is supposedly for working in a definition inside the muscles. In addition, no information such as to always expect a drop of certain significance in the bodybuilders weights which he is using.Any bodybuilder who believes this and goes ahead to carry it out devoid of a fight as well '''Testinate 250''' as allowing a decrease in training poundage is not serious in any way. This typifies one of the gravest of bodybuilding mistakes.Bad eating as well as drinking habits cripples up hard earned results.Bodybuilders should always be ready to develop proper dietary habits otherwise this will be an eventual mistake. Always as a serious bodybuilder stick to your protein requirements everyday. As a matter of fact reducing the amount of junk food such as burgers and pizzas would be a mistake avoided and a wise thing to do. Stick to your diet and unnecessary weight which you will need to work even harder to loss will never be a bother, otherwise thinking that you will lose weight even if you take junk food is a terrible stake. http://muscleshealthpro.com/testinate-250-review/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 12:01:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 12:01:39 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.291bf3537b942c6edddee439fe8c888c@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bernalex): Resubmitted abs without isNegativeZero to . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 13:12:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 13:12:08 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result Message-ID: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non- ghci non-llvm ways. For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 13:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 13:27:48 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result In-Reply-To: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> References: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> Message-ID: <062.13fc48eef86e026eb199ab1c79900a3d@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) 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): `popCnt8#` is affected too, but (possibly by luck, possibly not) we reuse the source register as the destination register and we needed to zero- extend the source anyways as there is no 8-bit `popcnt` instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 13:56:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 13:56:42 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.21f6d0206e04bd321250d092b06fade9@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D145 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 13:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 13:58:37 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.a339908d7d760f173fc0f90164243a66@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (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: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3669b60cb0b24e22563bfe624aab4aba369cbfca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3669b60cb0b24e22563bfe624aab4aba369cbfca" Add bit scan {forward,reverse} insns to x86 NCG This is a pre-requisite for implementing count-{leading,trailing}-zero prim-ops (re #9340) Reviewers: ezyang, rwbarton, simonmar, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 13:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 13:58:37 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.14e41235090658e9f67e1643d7a52e5f@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (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: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9f285fa40f6fb0c8495dbec771d798ac6dfaabee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9f285fa40f6fb0c8495dbec771d798ac6dfaabee" Add CMOVcc insns to x86 NCG This is a pre-requisite for implementing count-{leading,trailing}-zero prim-ops (re #9340) and may be useful to NCG to help turn some code into branch-less code sequences. Test Plan: Compiles and validates in combination with clz/ctz primop impl Reviewers: ezyang, rwbarton, simonmar, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 14:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 14:11:13 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result In-Reply-To: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> References: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> Message-ID: <062.1ebd7d66738b17eaf3121d620124160a@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D147 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D147 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 14:37:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 14:37:27 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.b6bbdda60f4fe04849893231f367357d@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Changes (by bernalex): * owner: => bernalex Comment: I'm going to write a patch using rwbarton's suggestion for signum, and test it with ghci and with various ghc optimisations tonight or tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:34:04 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result In-Reply-To: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> References: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> Message-ID: <062.7a789d3be84582ed99ce562b6706eb39@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D147 | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"64151913f1ed32ecfe17fcc40f7adc6cbfbb0bc1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="64151913f1ed32ecfe17fcc40f7adc6cbfbb0bc1" x86: zero extend the result of 16-bit popcnt instructions (#9435) Summary: The 'popcnt r16, r/m16' instruction only writes the low 16 bits of the destination register, so we have to zero-extend the result to a full word as popCnt16# is supposed to return a Word#. For popCnt8# we could instead zero-extend the input to 32 bits and then do a 32-bit popcnt, and not have to zero-extend the result. LLVM produces the 16-bit popcnt sequence with two zero extensions, though, and who am I to argue? Test Plan: - ran "make TEST=cgrun071 EXTRA_HC_OPTS=-msse42" - then ran again adding "WAY=optasm", and verified that the popcnt sequences we generate match the ones produced by LLVM for its @llvm.ctpop.* intrinsics Reviewers: austin, hvr, tibbe Reviewed By: austin, hvr, tibbe Subscribers: phaskell, hvr, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D147 GHC Trac Issues: #9435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:34:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:34:54 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result In-Reply-To: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> References: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> Message-ID: <062.d46411c0fe31d6e7f48b7ad1979e6b9b@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 (NCG) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D147 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge Comment: Marking as "merge" per hvr's suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:47 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.9b77c54ef641123681104c88ec58abdf@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: | ----------------------------------------+---------------------------------- Comment (by Richard Eisenberg ): In [changeset:"a09508b792eed24fc4d8a363df2635026bfa2de6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a09508b792eed24fc4d8a363df2635026bfa2de6" Test #9371 (indexed-types/should_fail/T9371) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:47 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.bd43086c9c5cd5fb3d9b141115f67d66@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: | ----------------------------------------+---------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f29bdfbcedda6cb33ab05d884c151f2b31f4e4e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f29bdfbcedda6cb33ab05d884c151f2b31f4e4e0" Fix Trac #9371. This was very simple: lists of different lengths are *maybe* apart, not *surely* apart. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:47 -0000 Subject: [GHC] #9415: Superclass cycle with ambiguous type causes loop In-Reply-To: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> References: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> Message-ID: <062.9ef5b53e623acf8fc83c49c3dd754bc0@haskell.org> #9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 Richard Eisenberg ): In [changeset:"1b1388697e687154c2bf1943639e75f3ccf5bc59/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1b1388697e687154c2bf1943639e75f3ccf5bc59" Fix #9415. Abort typechecking when we detect a superclass cycle error, as ambiguity checking in the presence of superclass cycle errors can cause a loop. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:48 -0000 Subject: [GHC] #9415: Superclass cycle with ambiguous type causes loop In-Reply-To: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> References: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> Message-ID: <062.19470cae38900233871eda45fca84eb4@haskell.org> #9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 Richard Eisenberg ): In [changeset:"1a3e19d061c1e5a1db9789572eca3a0ade450954/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1a3e19d061c1e5a1db9789572eca3a0ade450954" Test #9415 (typecheck/should_fail/T9415) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:59 -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.1d2673b278bc7d26b8b28ee42139d6a4@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 Richard Eisenberg ): In [changeset:"8d27c764aca6dba9ec150cb7e4d68d03e8a7e338/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8d27c764aca6dba9ec150cb7e4d68d03e8a7e338" Test #9200. (polykinds/T9200) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:45:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:45:59 -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.1aabf811143a22c2cec12ef7a7fdbd84@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 Richard Eisenberg ): In [changeset:"64859308231551de2aed839003994b29b99409c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="64859308231551de2aed839003994b29b99409c0" Change definition of CUSK for data and class definitions (#9200). Now, a CUSK is when (and only when) all type variables are annotated. This allows classes to participate in polymorphic recursion. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:46:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:46:00 -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.8c925725b50ccd1173f2d49402d0845e@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 Richard Eisenberg ): In [changeset:"3dfd3c33a46ae01a45802cb5b97fe7a2c8a8f31a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3dfd3c33a46ae01a45802cb5b97fe7a2c8a8f31a" Added more testing for #9200. (polykinds/T9200b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:46:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:46: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.caf032c749efe49113fbb2d09b78e0ee@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 Richard Eisenberg ): In [changeset:"b2c61670fced7a59d19c0665de23d38984f8d01c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b2c61670fced7a59d19c0665de23d38984f8d01c" Change treatment of CUSKs for synonyms and families (#9200). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:46:05 -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.21081e5a8f05547ca688190b063396f3@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 Richard Eisenberg ): In [changeset:"578377cec76d702da3714d4d6fe402b76de5aa7f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="578377cec76d702da3714d4d6fe402b76de5aa7f" Remove NonParametricKinds (#9200) This commit also removes 'KindCheckingStrategy' and related gubbins, instead including the notion of a CUSK into HsDecls. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:46:05 -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.6f408cf5ead7ec38f7086129799a7739@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 Richard Eisenberg ): In [changeset:"1c66b3d5d3d5f5b58e1860c33233a049b11e3d92/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1c66b3d5d3d5f5b58e1860c33233a049b11e3d92" Update manual (#9200). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:46:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:46: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.9525b4e3592ef04be498e8dd5e883cf0@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 Richard Eisenberg ): In [changeset:"91a48c5460258fdde800429df1e0d305cd2f0078/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="91a48c5460258fdde800429df1e0d305cd2f0078" Testsuite wibbles around #9200 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:50:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:50:37 -0000 Subject: [GHC] #9415: Superclass cycle with ambiguous type causes loop In-Reply-To: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> References: <047.4ec8abd880d85c1c64e1296abb8ae151@haskell.org> Message-ID: <062.6eb9ac858076b946327f197305844ee3@haskell.org> #9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge 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: | Blocked By: None/Unknown | Related Tickets: Test Case: | typecheck/should_fail/T9415 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T9415 * version: 7.9 => 7.8.3 * milestone: => 7.8.4 Comment: This is a proper bug with a simple fix and should be merged if we do 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:51:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:51:56 -0000 Subject: [GHC] #9371: Overlapping type families, segafult In-Reply-To: <044.67d504251b4c6afbb591b885728a5986@haskell.org> References: <044.67d504251b4c6afbb591b885728a5986@haskell.org> Message-ID: <059.3d6179cf4ec769e663ab773b182799fe@haskell.org> #9371: Overlapping type families, segafult -------------------------------------+------------------------------------- Reporter: pingu | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: indexed- | Related Tickets: types/should_fail/T9371 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => indexed-types/should_fail/T9371 * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 15:56:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 15:56:44 -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.c6bbaab0f999e11718b043583720ca6e@haskell.org> #9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 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: #9427 rejects valid program | Test Case: | polykinds/T9200 polykinds/T9200b | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => polykinds/T9200 polykinds/T9200b * resolution: => fixed * related: => #9427 * milestone: => 7.10.1 Comment: The above patches implement much of what was discussed here. They do ''not'' implement the "possible variation" part from the wiki page, as I ran out of time and the plumbing became a little challenging. See ticket #9427 to track the implementation of that piece. This is a user-facing, breaking change (in obscure circumstances) and should not be merged for 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 16:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 16:18:10 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.61828e18c1d9a71e71702bc37c7d078f@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): ok, now if we had a hypothetical `PolyTypeable` would you have other remaining needs for Any? It occurs to me as I'm saying this, that to some extent PolyTypeable is possible today via data/newtype wrapping a polymorphic type! For you use case, Is that a viable solution today (aesthetics aside) or is there a fundamental barrier to that being suitable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 16:19:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 16:19:26 -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.35e68b37304ab924cea553f53d68cf2f@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Building stage1 with the NCG made no difference, which is good, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 16:30:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 16:30:54 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.0a427da75b28c31237fa2c87db71abe2@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 16:43:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 16:43: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.f8521191495089a76d94202e2e40a6f5@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:32 rwbarton]: > Would you mind trying one more thing with LLVM 3.0 (with either the original or patched source tree)? Could you find the BuildFlavour stanza you are using in `mk/build.mk` (or just globally replace all of them if not sure) and change all occurrences of `-fllvm` to `-fllvm -fno-llvm- tbaa`? Curious if that would fix the issue. That did not appear to change anything for the better. I tried building the device (ARM) compiler with LLVM 3.4 but it failed. I suppose this is related to the info in comment:21. I'm trying now with the patch mentioned there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 17:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 17:21:43 -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.7c17c26ac54bf458ddee08d0d6a4fef7@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Aaaaaaaaa. So whatever changes I made to `mk/build.mk` didn't have the expected effect, for some reason, and the stage1 compiler was still being built with `-fllvm`. And of course the bootstrapping compiler has an LLVM mangler too, which goes about replacing `@function` with `@object` in the assembly output from LLVM. But I was building the mangler for the stage1 compiler with `-fllvm`, and of course it contains the string constant `@function` so that it knows what to replace with `@object`. So when the bootstrapping mangler mangled the stage1 mangler it also replaced that ''string constant'' `@function` by `@object` meaning the stage1 mangler was actually replacing `@object` with `@object`! So various things such as `ghczmprim_GHCziTypes_Czh_static_info` still had type `@function` after being mangled by the stage1 compiler, which led to this crash. Maybe we can tell LLVM to output `@object`s in the first place somehow? Or be more selective about our mangling... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 17:58:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 17:58:11 -0000 Subject: [GHC] #9436: Confusing error message with RecordWildCards Message-ID: <047.899387691d241ae17d7487e257f38c52@haskell.org> #9436: Confusing error message with RecordWildCards -------------------------------------+------------------------------------- Reporter: elliottt | 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: -------------------------------------+------------------------------------- When using the RecordWildCards extension, a confusing error message is given when the constructor name is invalid. For example, this module: {{{ {-# LANGUAGE RecordWildCards #-} module Test where data T = T { x :: Int } f :: T -> Int f T' { .. } = x + 1 }}} yields two error messages. The first is about the constructor T' not being in scope, and the second is a confusing message about how `..' is not valid in a record pattern: {{{ 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 Test ( Test.hs, interpreted ) Test.hs:8:3: Not in scope: data constructor ?T'? Perhaps you meant ?T? (line 5) Test.hs:8:3: You cannot use `..' in a record pattern Failed, modules loaded: none. }}} It seems like the second error should be left out in this case, as it's enough to report that the name isn't in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 18:22:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 18:22:23 -0000 Subject: [GHC] #9437: Wrong error message when using `..' with a record update Message-ID: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> #9437: Wrong error message when using `..' with a record update -------------------------------------+------------------------------------- Reporter: elliottt | 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: -------------------------------------+------------------------------------- Using `..' inside of a record update should report that it's an error to do so, but instead reports that it's an empty update. Consider this module: {{{ {-# LANGUAGE RecordWildCards #-} module Test where data Foo = Foo { x :: Int } test :: Foo -> Foo test foo = foo { .. } }}} When loaded, it complains about the empty record update of `foo`, instead of complaining about `..' being used during an update. {{{ 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 Test ( test.hs, interpreted ) test.hs:8:16: Empty record update of: foo Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 19:28:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 19:28:45 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.5e03abea0ce5234bc110e3d95908423a@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.9 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): Oh yes, of course. We want to wrap it in `build` to make it fuse with `map`. `reverse` inherently has lousy fusion behavior, but I think we should still do what we can. I think even improving the simple cases of `map f . reverse` and `reverse . map f` is sufficient to justify this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 19:51:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 19:51:55 -0000 Subject: [GHC] #9307: wave4main in nofib fails In-Reply-To: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> References: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> Message-ID: <057.566968f7975801c653b8b99daf34107b@haskell.org> #9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: NoFib | Version: 7.8.3 benchmark suite | Keywords: wave4main Resolution: | Architecture: x86_64 (amd64) Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: wave4main | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => low Comment: I'm pretty sure I know why this is happening. Basically this program's output is very sensitive to whether certain floating-point numbers that are very close to zero wind up being positive or negative. It might be worth tracking down exactly why the behavior differs when GHC is built with LLVM at some point though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 20:13:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 20:13:27 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.2c899367a92021cbcc0e726edfb698ef@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: D128 | -------------------------------------+------------------------------------- Comment (by Johan Tibell ): In [changeset:"6f862dfae20afdcd671133f3534b1bf5c25bbd9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6f862dfae20afdcd671133f3534b1bf5c25bbd9b" shouldInlinePrimOp: Fix Int overflow There were two overflow issues in shouldInlinePrimOp. The first one is due to a negative CmmInt literal being created if the array size was given as larger than 2^63-1 (on a 64-bit platform.) This meant that large array sizes could compare as being smaller than maxInlineAllocSize. The second issue is that we casted the Integer to an Int in the comparison, which again meant that large array sizes could compare as being smaller than maxInlineAllocSize. The attempt to allocate a large array inline then caused a segfault. Fixes #9416. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 20:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 20:15:49 -0000 Subject: [GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) In-Reply-To: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> References: <045.41e11a8e1d9c6b4e1206e1415f591473@haskell.org> Message-ID: <060.8025a4ce33c3a448331b62c530d8dd0d@haskell.org> #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | 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: D128 | -------------------------------------+------------------------------------- Changes (by tibbe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 20:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 20:21:44 -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.d1511960dd218d559d3c2e75b5ad336b@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: #8976 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #8976 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 21:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 21:44:12 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.abb1e9d883aa4123ccbebb73799a0243@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): GHC's out-of-date version of MinGW-w64 currently prevents me from developing a Windows version of [https://github.com/RyanGlScott/bluetooth Bluetooth libraries for Haskell]. GHC's version of MinGW-w64 (2.0) [http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/10121 doesn't pack the necessary Bluetooth structs correctly], whereas the current version (3.1) does. Attempting to link against the most recent MinGW-w64's libraries results in problems as well, since the Bluetooth-related headers have changed substantially (e.g., the [http://sourceforge.net/p/mingw-w64/bugs/355/ NS_BTH macro] was introduced), and compilation often results in [https://ghc.haskell.org/trac/ghc/ticket/7056 this issue] (usually with {{{cabal repl}}}). In addition, the Bluetooth functionality is not available on MinGW, only on MinGW-w64, so switching to minGW-w64 for both Windows architectures would allow me to develop for 32-bit Windows as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 12 22:43:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Aug 2014 22:43:31 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.bcb124e14139482fe5a14645d0b6045e@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:10 carter]: > ok, now if we had a hypothetical `PolyTypeable` would you have other remaining needs for Any? I myself wouldn't. I don't know of other use cases beyond the ones internal to GHC. > It occurs to me as I'm saying this, that to some extent PolyTypeable is possible today via data/newtype wrapping a polymorphic type! For you use case, Is that a viable solution today (aesthetics aside) or is there a fundamental barrier to that being suitable? Interesting idea. But I'm afraid it isn't a solution without its problems, beyond the mere verbosity that it might induce. If I understand your idea correctly, you're saying that if you want to send say `bind`, then you introduce the following type and wrap `bind`: {{{ data Dict c = c => Dict newtype BindWrap = BindWrap (forall a m. Dict (Monad m) -> m a -> (a -> m b) -> m b) bindWrap = BindWrap $ \Dict -> (>>=) }}} Now, you can send a label for `bindWrap` to the remote side, along with the `TypeRep` for `BindWrap`. But you can't compose `bindWrap`. That is, `bindWrap` is a "static value" in the sense that it doesn't depend on any other runtime "dynamic" value. In other words, it has no free variables. If we say that labels for static values `x :: a` have type `Static a`, then I can't combine `bindWrap` with say `action :: Static [Int]` using {{{ staticApply :: Static (a -> b) -> Static a -> Static b }}} because `bindWrap` is of atomic type. The only reasonable type that I can give to any label for it is `Static BindWrap`. But that's not a `Static` with an arrow type index. So while you can send `bindWrap`, you can't send compositions of it with other `Static` things. This is an important feature for many Cloud Haskell use cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 13:22:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 13:22:42 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.e0842afa319d5f1a6cdd06068cf50b0c@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rrnewton): Hi all, Uh uh! Our approach to lock-free data structures in Haskell (atomic- primops, chaselev-deque, lockfree-queue, concurrent-skiplist) is based on `Any`. The way we use Any is simply to prevent GHC from performing any optimizations that change the pointer identity of the object. That is, the "Ticket" type in atomic-primops is really just an Any. Is there some other way to accomplish this goal via other means in GHC head? Perhaps we need something like NOINLINE... Johan's been adding more and better atomic memory primop support in HEAD but it sounds like this is at cross purposes with Any also being removed from HEAD! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 13:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 13:23:28 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.d31a5dfaa8cca4f59d3cf74d7ebfb0ac@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rrnewton): * cc: rrnewton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 14:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 14:01:41 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.5a2d830d94dec41d4e824d78b4d54a6e@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): See also [http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/ this ghc-devs thread] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 14:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 14:21:36 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.875b0ef9a58fc68be8d7a3b6525ee210@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): There's another use of `Any` that I'm aware of that might not work anymore, to create unique tombstone values that can be compare using `reallyUnsafePtrEquality#`. See e.g. https://github.com/gregorycollins/hashtables/blob/8a1ed23450377360e4b53b83c531f7557fff7e79/src/Data/HashTable/Internal/UnsafeTricks.hs#L38. These tricks allow you to write a `Maybe a` represents null values (or any number of unary constructors) using a designated pointer instead of an indirection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 14:22:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 14:22:18 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.e2d1c3d8a61f24ec7764d6919d126b7c@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * cc: GregoryCollins (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 14:48:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 14:48:11 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.c8307ff0a7bd2742d59c1c3ad7980d15@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): It's not clear to me that Ryan's and Johan's uses are in conflict with the `Any` change. `Any` is still around and still usable in HEAD. It just can't appear in a type pattern -- that is, on the LHS of a type family equation or in an instance head. Is `Any` used in this way in the programs cited above? In particular, it assuredly ''is'' still possible to cast to `Any` and then cast back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 15:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 15:49:03 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.3837be80ea01ae106e6c05112f6ab6e7@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Design notes are available [https://ghc.haskell.org/trac/ghc/wiki/StaticValues here]. Please, feel free to comment or ask for refinements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 16:10:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 16:10:42 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.eff2796f8bc6d6fd1454e14864c53b0c@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rrnewton): Oh, there may be no problem then. I misread and thought Any was gone in its previous form. I'll test it and try to get our packages working on GHC head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 13 19:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Aug 2014 19:21:36 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.2728d30e7958cece0a2f3eb42b2d1f84@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: x86 Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dmcclean): * difficulty: => Unknown Comment: I have a similar error on 7.8.3 on Windows. I can't see anything remarkable about the function it complains about. Calls to it seem to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 01:16:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 01:16:36 -0000 Subject: [GHC] #9438: panic: loading archives not supported Message-ID: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> #9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 04:20:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 04:20:59 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code Message-ID: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: -------------------------------------+------------------------------------- In an attempt to close #4210 the LLVM code generator's mangler was modified in ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables. Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues. This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 04:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 04:21:43 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.a2a7b77874bc17ac84d70ead32c001bc@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.2 (LLVM) | 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 bgamari): * cc: rwbarton@? (added) * owner: => bgamari * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 04:29:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 04:29:36 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.fd2480b500b568790d9121df3c4cfcb9@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.2 (LLVM) | 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: D150 | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => D150 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 04:47:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 04:47:50 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis Message-ID: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | 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: -------------------------------------+------------------------------------- Occurrence analysis on case alternatives performs a "binder swap", whereby occurrences of the scrutinee in alternative RHSs are replaced by the case binder when the scrutinee is a variable or a casted variable. {{{ case x of w C vs -> rhs === case x of w C vs -> let x = w in rhs }}} This should check two conditions, mentioned in Note [Binder swap]. (a) x is free in `C vs -> rhs`, otherwise one of two bad things happen: 1) it is pointless 2) new binding of x would capture one of the alternative binders (vs) (b) w is not in vs Neither of these conditions is actually being checked. Additionally, the binder swap happens in the presence of casts: {{{ case x |> co of w C vs -> rhs === case x |> co of w C vs -> let x = w |> sym co in rhs }}} But the analysis is not returning usage info for free coercion variables in co. Condition (a) bit us in HERMIT when running `occurAnalyseExpr` on the following expression resulting from unfolding nested calls to `fst`: {{{ case x_X11b of wild_a3YB (,) x_a3YD ds1_a3YE -> case x_a3YD of wild_a3YB (,) x_a3YD ds1_a3YE -> x_a3YD }}} The analysis would erroneously result in: {{{ case x_X11b of wild_a3YB (,) x_a3YD ds1_a3YE -> case x_a3YD of wild_a3YB (,) x_a3YD ds1_a3YE -> let x_a3YD = wild_a3YB in x_a3YD }}} which is clearly Not Good. Patch forthcoming via Phabricator. Unfortunately, I don't have a good test case that doesn't involve HERMIT, but can confirm this patch fixes the problem above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 04:56:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 04:56:44 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.47616dc9d06cd60815efef67cd8b249d@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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: D156 | -------------------------------------+------------------------------------- Changes (by afarmer): * status: new => patch * differential: => D156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 05:06:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 05:06:50 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.93f94c6be34ddcb12bfebb1a46d5eb17@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D156 => Phab:D156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 07:00:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 07:00:52 -0000 Subject: [GHC] #9441: Merge identical top-level expressions following simplification when it is safe to do so Message-ID: <045.987758d932a89023c69da6c12f8363f5@haskell.org> #9441: Merge identical top-level expressions following simplification when it is safe to do so -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- If I redefine {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} and then write a couple test cases: {{{#!hs appRev xs ys = xs ++ reverse ys revAppRev xs ys = reverse xs ++ reverse ys }}} I end up getting some rather annoying code duplication (lots of stuff omitted from the following): {{{#!hs Rec { poly_go_r2v3 poly_go_r2v3 = \ @ a_a2nF ds_a2zc eta_Xl -> case ds_a2zc of _ { [] -> eta_Xl; : y_a2zh ys_a2zi -> poly_go_r2v3 ys_a2zi (: y_a2zh eta_Xl) } end Rec } reverse reverse = \ @ a_a2nF eta_B1 -> poly_go_r2v3 eta_B1 ([]) Rec { revAppRev2 revAppRev2 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev2 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { revAppRev1 revAppRev1 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { appRev1 appRev1 = \ @ a_a2xE ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> appRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } }}} The `reverse` function was inlined three times. In each case, there was no fusion, so `build` was inlined and the resulting copy of the `reverse` worker lifted to the top level. It would seem to me that once simplification is complete, it should be safe to merge all these copies into one. They are all `Rec {\ ... -> ...}` forms, so I don't think this has any potential to introduce undesirable sharing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 08:22:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 08:22:49 -0000 Subject: [GHC] #9442: Building GHC with Clang Message-ID: <047.60025353427d2f2c7d3fc692e6f27863@haskell.org> #9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: -------------------------------------+------------------------------------- How does one build GHC from scratch using Clang on OS X 10.9 and 10.10? At this time, I'm seeing the following message: $ ./configure checking for gfind... /opt/local/bin/gfind checking for sort... /usr/bin/sort checking for GHC version date... inferred 7.9.20140813 checking for ghc... no configure: error: GHC is required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 10:16:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 10:16:33 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" Message-ID: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This file works fine with 7.6.3: But with 7.8.3, every newtype has an error message like: {{{ Could not coerce from ?TimeUnit Integer? to ?TimeUnit (Year a)? || because the first type argument of ?TimeUnit? has role Nominal, || but the arguments ?Integer? and ?Year a? differ || arising from the coercion of the method ?timeVal? from type || ?forall n. (TimeUnit Integer, Num n) => Integer -> n? to type || ?forall n. (TimeUnit (Year a), Num n) => Year a -> n? }}} To make the code work again, I need to remove a redundant type constraint from: {{{#!hs class TimeUnit t where timeVal :: (TimeUnit t, Num n) => t -> n }}} Turning it into: {{{#!hs class TimeUnit t where timeVal :: Num n => t -> n }}} The constraint is redundant because it is already implied by 'class TimeUnit t'. I suspect this is a regression. I would be happy to work on it, but I don't have time right now, so I'm putting it here for visibility, feedback, and to remember it in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 10:29:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 10:29:37 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.63893c8de872d1bc5c24923dd2d84951@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz (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: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e0c1767d0ea8d12e0a4badf43682a08784e379c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e0c1767d0ea8d12e0a4badf43682a08784e379c6" Implement new CLZ and CTZ primops (re #9340) This implements the new primops clz#, clz32#, clz64#, ctz#, ctz32#, ctz64# which provide efficient implementations of the popular count-leading-zero and count-trailing-zero respectively (see testcase for a pure Haskell reference implementation). On x86, NCG as well as LLVM generates code based on the BSF/BSR instructions (which need extra logic to make the 0-case well-defined). Test Plan: validate and succesful tests on i686 and amd64 Reviewers: rwbarton, simonmar, ezyang, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D144 GHC Trac Issues: #9340 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 10:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 10:35:12 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.a40d010d92cbef2fc00b74e1a1c5a71e@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | 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 Aug 14 10:35:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 10:35:37 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.39976ddacc01eb73f79a680c05258fd5@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bernalex): * cc: slyfox (removed) * cc: eir@?, slyich@?, haskell@? (added) Comment: Nilkas and Trofi helped me out a bit. It seems this is due to the new role-inference mechanism. As such, it's perhaps not a regression per se. I do think GHC should accept this as a valid program though. CC'ing Richard, as Trofi mentioned that he was the GND/roles guy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 10:40:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 10:40:24 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.f1744eab07ea5b40795fab5f4e2dee41@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by bernalex: Old description: > This file works fine with 7.6.3: > > > But with 7.8.3, every newtype has an error message like: > {{{ > Could not coerce from ?TimeUnit Integer? to ?TimeUnit (Year a)? > || because the first type argument of ?TimeUnit? has role Nominal, > || but the arguments ?Integer? and ?Year a? differ > || arising from the coercion of the method ?timeVal? from type > || ?forall n. (TimeUnit Integer, Num n) => Integer -> n? > to type > || ?forall n. (TimeUnit (Year a), Num n) => Year a -> n? > }}} > > To make the code work again, I need to remove a redundant type constraint > from: > {{{#!hs > class TimeUnit t where timeVal :: (TimeUnit t, Num n) => t -> n > }}} > > Turning it into: > {{{#!hs > class TimeUnit t where timeVal :: Num n => t -> n > }}} > > The constraint is redundant because it is already implied by 'class > TimeUnit t'. > > I suspect this is a regression. I would be happy to work on it, but I > don't have time right now, so I'm putting it here for visibility, > feedback, and to remember it in the first place. New description: This file works fine with 7.6.3: But with 7.8.3, every newtype has an error message like: {{{ Could not coerce from ?TimeUnit Integer? to ?TimeUnit (Year a)? || because the first type argument of ?TimeUnit? has role Nominal, || but the arguments ?Integer? and ?Year a? differ || arising from the coercion of the method ?timeVal? from type || ?forall n. (TimeUnit Integer, Num n) => Integer -> n? to type || ?forall n. (TimeUnit (Year a), Num n) => Year a -> n? }}} To make the code work again, I need to remove a redundant type constraint from: {{{#!hs class TimeUnit t where timeVal :: (TimeUnit t, Num n) => t -> n }}} Turning it into: {{{#!hs class TimeUnit t where timeVal :: Num n => t -> n }}} The constraint is redundant because it is already implied by 'class TimeUnit t'. I suspect this is a regression. I would be happy to work on it, but I don't have time right now, so I'm putting it here for visibility, feedback, and to remember it in the first place. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 11:49:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 11:49:09 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.84d5f9b716001a6b4ac7f6cc122ef12a@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz ctz (CodeGen) | 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: Phab:D144 | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: primop clz => primop clz ctz * status: patch => closed * resolution: => fixed Comment: I consider this ticket resolved. The next step will be to expose those primops via `Data.Bits` (see Phab:D158 for a draft-patch which still needs to go through the library proposal process) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 12:28:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 12:28:00 -0000 Subject: [GHC] #9444: -ddump-deriv doesn't dump failed newtype-deriving Message-ID: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> #9444: -ddump-deriv doesn't dump failed newtype-deriving -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- When I say {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} {-# OPTIONS_GHC -ddump-deriv #-} type family F a type instance F Int = Bool class C a where meth :: a -> F a instance C Int where meth = (> 0) newtype Age = MkAge Int deriving C }}} I get an error (which I should), but I don't get the derived `C` instance, as requested by `-ddump-deriv`. The output should include this helpful information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 12:36:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 12:36:00 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.13bbd90a3846ae52d6ec5a18a4776822@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't think this is a bug, but I suppose I could be convinced otherwise. Consider this: {{{#!hs class C a where meth :: D a => a -> a }}} Note that the constraint on `meth` is ''not'' `C a`, but some other class `D a`. If we wish to derive an instance of `C` via GND, the derived instance will use the exact same implementation of `meth` as does the original instance. BUT, the newtype (say, `Year a`) may have a ''different'' instance for `D` compared to the representation type (`Integer`). So, reusing the old implementation would be bogus. That's why class parameters default to have nominal roles. Of course, if we knew that the `D` instances were in fact the same, then the derivation makes good sense. But GHC doesn't track "instance equality" (which could just mean that one instance is the GND of the other). In the case presented here, the instance equality is guaranteed, as we're performing the GND to make the instances equal. However, detecting this, in general, is hard, and this seems like enough of a corner case to let it go unfixed. Does that explain it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 13:48:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 13:48:43 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.f5077f8e0f1c8aa43f3713e5f93a923c@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by boo): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 13:49:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 13:49:08 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.fb95603bdfc94bbff945d769963859c1@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by boo): I confirm this bug. Trying to compile GHC-7.8.3 on Raspberry Pi and get this error: {{{ ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-p-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 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Aborted Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 16:01:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 16:01:35 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.7ac82961c7b872f478267a22c6927d2c@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by rwbarton): * related: => #8976 Old description: > 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 New description: 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 }}} -- Comment: Probably the same issue as #8976. Are you using gold or bfd ld? We have a patch in preparation right now that ''might'' address this, stay tuned! But check the comments on #8976 first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 18:59:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 18:59:25 -0000 Subject: [GHC] #9442: Building GHC with Clang In-Reply-To: <047.60025353427d2f2c7d3fc692e6f27863@haskell.org> References: <047.60025353427d2f2c7d3fc692e6f27863@haskell.org> Message-ID: <062.7e8b60d70065c2ab25f4cd66d0dc656f@haskell.org> #9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by hvr): Have you consulted wiki:Building already? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 20:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 20:21:56 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor Message-ID: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: panic | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: 5539 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello guys, this is an old bug which has been reported so many times that I'm not sure this will be noise or something useful. In a nutshell I have been hit by this bug installing the library "SFML", which relies heavily on FFI. The only interesting thing of this report is that it was necessary an very high simpl-factor to make the installation go through! Pre-bump: {{{ Resolving dependencies... In order, the following will be installed: SFML-0.2.0.0 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [...] [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sZQW{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 2655928 }}} And this was the magic line: {{{ cabal install SFML --ghc-option=-fsimpl-tick-factor=1630 }}} HTH, it turns out it's quite an annoying one! And yes, "1630" was the smaller factor which made the installation possible. Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 20:28:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 20:28:08 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.b6105f7ed58a5e3a169b7d15c5a0b761@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by boo): It seems, that I use bfd ld, but after changing link from /usr/bin/ld to ld.gold I get the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 14 21:27:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Aug 2014 21:27:22 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.abeb551a5cdef61a89d4b6fbd9d4e07c@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by haasn): I agree that the class definition you gave should not be allowed. The bug as presented here is a very special case, namely the case where we have: {{{ class C a where meth :: C a => a -> a }}} This constraint is redundant because the context already implies it. So a fix for this issue would ''not'' necessarily imply allowing instance coercions in general - it would only allow instance coercions in the context of an instance coercion for that same instance, which is a rather minor detail. If this can be fixed easily, that's good; but if it can't, I don't think there's much of a loss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 05:47:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 05:47:46 -0000 Subject: [GHC] #9446: Segfault when using unsafe vector operations Message-ID: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> #9446: Segfault when using unsafe vector operations ----------------------------------+---------------------------------------- Reporter: snoyberg | 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: ----------------------------------+---------------------------------------- I was working on some benchmarks and I ran into this issue. It's actually very difficult to reproduce; changing the attached file in different ways makes the bug go away quite quickly. But with the attached file, I regularly get a `internal error: evacuate: strange closure type 0` message, though on more complicated versions of the code I was working on, the integer would change for each run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 11:08:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 11:08:18 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.12873cc0e3db872000dd1808755070fe@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bernalex): I fully agree with Niklas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 12:05:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 12:05:24 -0000 Subject: [GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" In-Reply-To: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> References: <047.7d981c90d0a10cf893312ccd8539b836@haskell.org> Message-ID: <062.2332b878d4183bdd5999753b6de21d8f@haskell.org> #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: wontfix | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: The way to handle the original case is to detect the redundant constraint and eliminate it, before doing any other processing. However, GHC does not do this currently, and the choice would have runtime consequences I think -- it would speed programs up, which now have fewer dictionaries to pass. I'm not inclined to make this change: perhaps the user has good reasons for the redundancy. Short of that, I don't see a way to fix this without contortions. Given the comments above, I'm closing as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 13:31:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 13:31:47 -0000 Subject: [GHC] #9446: Segfault when using unsafe vector operations In-Reply-To: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> References: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> Message-ID: <062.24fcbb2438cdf3b257579a6493ccd97a@haskell.org> #9446: Segfault when using unsafe vector operations ----------------------------------------+---------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | 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 rwbarton): * status: new => closed * resolution: => invalid Comment: `slice` is non-copying, and so `unsafeFreeze` on a `slice` freezes the underlying vector. You can't then later write to the mutable vector that has been frozen without confusing the GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 14:26:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 14:26:46 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.a4185e00f67e04e22612e91f5545fc23@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost in this thread. As Richard says (comment:17), * `Any` is still a valid type that can inhabit any kind * but you can't pattern-match on it in an instance declaration There are good reasons for this design. One that has not been mentioned so far is #7259: eta expansion of products. Admittedly we don't have this now, but in some sense we should have, and I'd be reluctant to move to a design that precluded it. If there is still a lack, could someone articulate just what it is, preferably explicitly (articulating problem, solution) rather than by saying that `rank1dyanamic` doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 14:46:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 14:46:40 -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.77181cc2abaf8b043254410113038a11@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: 9439 Test Case: | Related Tickets: #8976 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * blockedby: => 9439 Comment: This should be fixed when #9439 is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 14:47:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 14:47:28 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.648747d59e6635c1350e76830530da74@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: bgamari => rwbarton * differential: D150 => Phab:D150 * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 14:58:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 14:58:54 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.32e78b021f87c91f01e47a23bccbf564@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.9 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 simonpj): Great. Just check that when fusion ''doesn't'' take place, the result is good. And do a `nofib` comparison for good luck. Then submit a patch. Thanks for doing all this work on fusion, David. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 15:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 15:39:05 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.17c2b3795c48b2575396fe06fef1b35c@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Comment (by simonpj): That's terrible! Than you for spotting this. Re (a), I'm not sure how convenient it is to check that `x` is free in `C vs -> rhs`. Perhaps it is easy. But if not, you could instead just check that `x` is not in `vs`. That could conveniently be done with checking (b). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 15:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 15:56:09 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.0118adabb0f42434aa2dac59fe8b9b2d@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"5895f2b8ffba72a8393e9f712461e6e5ed7ceced/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5895f2b8ffba72a8393e9f712461e6e5ed7ceced" LlvmMangler: Be more selective when mangling object types Summary: We previously did a wholesale replace of `%function` to `%object` to mangle object `.type` annotations. This is bad as it can end up replacing appearances of `"%function"` in the user's code. We now look for a proper `.type` keyword before performing the replacement. Thanks to @rwbarton for pointing out the bug. Test Plan: Previously, $ echo 'main = putStrLn "@function"' > test.hs $ ghc -fllvm test.hs $ ./test @object Now, $ echo 'main = putStrLn "@function"' > test.hs $ ghc -fllvm test.hs $ ./test @function Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D150 GHC Trac Issues: #9439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 15:56:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 15:56:52 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.ed90a3be2eefca5e3ce13d4fc3aee8cf@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: rwbarton => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 15:57:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 15:57:02 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.9dc9d265937a9518f243d86fe2d2d3ab@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 16:02:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 16:02:15 -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.c9104b421b2ff0d4f26dc73597abd43c@haskell.org> #9268: internal error: evacuate(static): strange closure type -385875968 -------------------------------------+------------------------------------- Reporter: brbr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: 9439 Test Case: | Related Tickets: #8976 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is now fixed in HEAD. Note that you probably need to use a bootstrapping compiler that is not affected by this bug, currently meaning 7.6.3 or earlier. trac doesn't want to let me close the ticket because it's blocked by #9439 which is in 'merge' status. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 16:03:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 16:03:53 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.5b5921955d1bc2bfe32762e01bfd1b63@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): Can you try building the latest HEAD? You will probably need to use 7.6.3 as your bootstrapping compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 16:04:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 16:04:41 -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.7cc9d3f2f0c25d5d24d52f2cbfa85520@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #9268 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): #9268 is fixed in HEAD, can you try building that? You will probably need to use 7.6.3 as your bootstrapping compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 16:12:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 16:12:44 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.782a946f034537d68a24f6832831e8fc@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Comment (by afarmer): (a) turned out to be easy enough, I just tagged the binders before checking for usage in the alt. (b) and the coercion variables required a slight bit of refactoring. See the Phab:D156 patch for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 17:21:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 17:21:03 -0000 Subject: [GHC] #9446: Segfault when using unsafe vector operations In-Reply-To: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> References: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> Message-ID: <062.063d4987fb35937ef851a9b37d88d220@haskell.org> #9446: Segfault when using unsafe vector operations ----------------------------------------+---------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | 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 klao): * cc: klao@? (added) Comment: Hmm, this sounds quite restrictive. So, do I understand correctly that there is no way to freeze a part of a mutable vector? Even if I know that that part will not change? Can you point to a relevant description of this part of the GC? I'd like to understand the situation better to figure out what kind of work-around is possible (if at all). Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 18:32:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 18:32:31 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.5c4baca742f67aa4759478e3f580285d@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 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 Lemming): * cc: ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 15 20:18:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Aug 2014 20:18:02 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.ce0a2ca66ab27ac750198bb6afa7566b@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by boo): I started to build HEAD by GHC-7.6.3, but I have RPi with only 256 MB of RAM. It will take some time, I think 2 or 3 days... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 16 13:49:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Aug 2014 13:49:52 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s Message-ID: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | 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: Phab:D133 -------------------------------------+------------------------------------- This is motivated by #9281 which changes how memory is allocated, and gives rise to the need to be able to efficiently shrink or grow `MutableByteArray#`s before they're frozen into `ByteArray#` while retaining their original byte content to avoid a major bottle-neck. This ticket is for tracking/documenting all changes related to this new facility. Here's the current road-map: 1. Implement {{{#!hs shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s resizeMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s, MutableByteArray# s #) }}} (see Phab:D133) 2. As suggested by Johan, {{{#!hs getSizeofMutableByteArray# :: MutableByteArray# s -> State# s -> (# State# s Int# #) }}} This is similar in spirit to `numCapabilities` and `getNumCapabilities`. Add a deprecate pragma (or equivalent) for `sizeofMutableByteArray#`. Add a note to `sizeofMutableByteArray#` stating that it's unsafe in the presence of calls to resize-operations on the same MBA. 3. Submit patches to upstream libraries replacing calls to `sizeofMutableByteArray#` with `getSizeofMutableByteArray#` 4. Investigate how to provide in-place (zero-copy) growing of MBAs (step 1. only implements in-place shrinking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 16 14:04:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Aug 2014 14:04:39 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s In-Reply-To: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> References: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> Message-ID: <057.9d1f3e3b560d596d9e3f53a41f217ee8@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | 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: Phab:D133 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"246436f13739593d2a211ceb830393338118ca4d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="246436f13739593d2a211ceb830393338118ca4d" Implement {resize,shrink}MutableByteArray# primops The two new primops with the type-signatures resizeMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> (# State# s, MutableByteArray# s #) shrinkMutableByteArray# :: MutableByteArray# s -> Int# -> State# s -> State# s allow to resize MutableByteArray#s in-place (when possible), and are useful for algorithms where memory is temporarily over-allocated. The motivating use-case is for implementing integer backends, where the final target size of the result is either N or N+1, and only known after the operation has been performed. A future commit will implement a stateful variant of the `sizeofMutableByteArray#` operation (see #9447 for details), since now the size of a `MutableByteArray#` may change over its lifetime (i.e before it gets frozen or GCed). Test Plan: ./validate --slow Reviewers: ezyang, austin, simonmar Reviewed By: austin, simonmar Differential Revision: https://phabricator.haskell.org/D133 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 16 18:49:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Aug 2014 18:49:43 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.0144e93078c5da8f35efded87a0bc650@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by boo): Unfortunately, I got the following error: {{{ ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:19: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:25: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:27: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:27: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist- boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist- boot/build/.depend-v.haskell: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/terminfo/ghc.mk:3: libraries/terminfo/dist- boot/build/.depend-v.haskell: No such file or directory libraries/terminfo/ghc.mk:3: libraries/terminfo/dist- boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:645: compiler/stage1/build/.depend-v.haskell: No such file or directory inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" In file included from includes/Stg.h:272:0, from includes/Rts.h:30, from includes/dist-derivedconstants/header/tmp.c:13: includes/stg/SMP.h: In function ?store_load_barrier?: includes/stg/SMP.h:338:2: error: #error memory barriers unimplemented on this architecture includes/stg/SMP.h: In function ?load_load_barrier?: includes/stg/SMP.h:358:2: error: #error memory barriers unimplemented on this architecture Executing "/usr/bin/gcc" failed includes/ghc.mk:167: recipe for target 'includes/dist- derivedconstants/header/DerivedConstants.h' failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 16 19:19:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Aug 2014 19:19:25 -0000 Subject: [GHC] #9448: Clarify documentation of a quasi-quoter form Message-ID: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> #9448: Clarify documentation of a quasi-quoter form -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- According to http://www.haskell.org/ghc/docs/latest/html/users_guide /template-haskell.html#th-quasiquotation, for quasi-quoter form {{{#!hs [quoter| string |] }}} The quoter must be the (unqualified) name of an imported quoter. But according to #5555 ticket, qualified quoters are allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 00:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 00:58:25 -0000 Subject: [GHC] #9449: GHC.Prim documentation says "Safe Inferred" Message-ID: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> #9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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 Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus. When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 05:25:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 05:25:01 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.10128f2b69fa59af5e493b57f0aec0d1@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Changes (by tejon): * cc: hvr (added) Comment: I am attempting to run the test code for helm, which depends on gtk and sdl2. **As in the main ticket case, compiling with GHC works fine.** I ran into the "GHCi can't find m.dll" issue on the pango dependency, but fixed it using fryguybob's suggestion. Sadly, I run into a similar issue on the sdl2 dependency: {{{ Loading package sdl2-1.1.0 ... : mingw32: The specified module could not be found. can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL) }}} Relinking libmingw32.a into a dll was problematic: the .a contains both dllmain.o and a spurious main.o (which I removed), and also a pair of objects crtst.o and tlsmcrt.o which each do nothing but declare the same integer (a threading state flag), leading to a duplicate declaration error; I have tried favoring each, with the same result. Linking the remainder into mingw32.dll, I now get this: {{{ Loading package sdl2-1.1.0 ... : Unknown PEi386 section name `.rdata$IID_IBindStatusCallback' (while processing: C:/msys/lib\libSDL2.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadArchive "C:/msys/lib\\libSDL2.a": failed }}} Perhaps mangling the relink broke everything, but I don't believe it should have gotten that far in the first place: like the m.dll issue this seems to arise from GHCi's inability to identify libfoo.a with foo.dll. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 07:51:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 07:51:51 -0000 Subject: [GHC] #9446: Segfault when using unsafe vector operations In-Reply-To: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> References: <047.77649d6bd1c067e5ed4c2e5bc3732d8e@haskell.org> Message-ID: <062.34b2d2979c4ecfa53e2e47ccfab984a3@haskell.org> #9446: Segfault when using unsafe vector operations ----------------------------------------+---------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | 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 snoyberg): I've attached a new file, vector-bug-fixed.hs, which (inspired by some attoparsec code) thaws an immutable vector before writing to it, which seems to address the issue. I have not investigated the performance impact of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 09:48:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 09:48:41 -0000 Subject: [GHC] #9450: GHC instantiates Data instances before checking hs-boot files Message-ID: <044.e97ab0330439b82d1df8c46c46f1a39d@haskell.org> #9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: boot,deriving | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling a file with deriving instances in it and making use of boot files, it appears that the derivation is attempted before the boot files are checked for consistency. This can lead to GHC panics, as when compiling GHC after this commit https://github.com/alanz/ghc/commit/c73182ca7345f0debba47d0b17a907bcac27c41f In the attached files, if you try to load HsLit.lhs into ghci it will complain about the missing Data instance, not about the boot file inconsistency. If you remove the Data from the deriving clause of HsOverLit, it complains about the boot file inconsistency. I have not managed to reproduce the original panic in this stripped down environment, but if it is needed to more fully understand the problem I can try again to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 10:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 10:21:19 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.6846ef4cb5dc6a55ee479155f8d6f8c8@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by jrp): Today's results: {{{ Unexpected results from: TEST="T367_letnoescape conc012 joao-circular enum01 topHandler03 enum03 enum02 hpc_markup_001 T5321FD T5030 T4801 T6048 T5631 T783 T5642 T9020 T3064 parsing001 T1969 T5321Fun T5837 T3294 cabal06 T5435_dyn_asm" OVERALL SUMMARY for test run started at Sat Aug 16 23:05:03 2014 BST 0:35:47 spent to go through 4088 total tests, which gave rise to 16032 test cases, of which 3412 were skipped 315 had missing libraries 12108 expected passes 149 expected failures 3 caused framework failures 0 unexpected passes 45 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) ../../libraries/hpc/tests/simple/tixs hpc_markup_001 [bad stdout] (normal) cabal/cabal06 cabal06 [bad stdout] (normal) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) programs/joao-circular joao-circular [exit code non-0] (hpc) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 10:24:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 10:24:25 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.e12c05b1346d62199c0ab8f3d58d2cf0@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHC | Difficulty: Unknown rejects valid program | Blocked By: Test Case: enum01.hs | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I think that the test should be fixed to make it Clang-compatible. That way it will test enum, which is what it is supposed to do. The same applies to enum02-04. We should then have another test specifically for cpp behaviour. (I would do this, but don't have commit access.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 11:10:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 11:10:41 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.be3a2d8bc13a1080e1ffc19a497b3b27@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz ctz (CodeGen) | 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: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"6375934bfe64ca15eb215327629f9f07a185377a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6375934bfe64ca15eb215327629f9f07a185377a" Workaround GCC `__ctzdi2` intrinsic linker errors On Linux/i386 the 64bit `__builtin_ctzll()` instrinsic doesn't get inlined by GCC but rather a short `__ctzdi2` runtime function is inserted when needed into compiled object files. This causes failures for the four test-cases TEST="T8639_api T8628 dynCompileExpr T5313" with error messages of the kind dynCompileExpr: .../libraries/ghc-prim/dist- install/build/libHSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.a: unknown symbol `__ctzdi2' dynCompileExpr: dynCompileExpr: unable to load package `ghc-prim' This workaround forces GCC on 32bit x86 to to express `hs_ctz64` in terms of the 32bit `__builtin_ctz()` (this is no loss, as there's no 64bit BSF instruction on i686 anyway) and thus avoid the problematic out-of-line runtime function. Note: `__builtin_ctzll()` is used since e0c1767d0ea8d12e0a4badf43682a08784e379c6 (re #9340) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 11:24:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 11:24:02 -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.6df75ac87b6987096dfbcf078b188878@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 Herbert Valerio Riedel ): In [changeset:"96d04186e00fe2202b9953688492bb370d818bf1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96d04186e00fe2202b9953688492bb370d818bf1" Remove obsolete `digitsTyConKey :: Unique` This became dead with 1e87c0a6e485e1dbef8e9ed19191e54f6cdc54e0 and was probably just missed. I plan to re-use the freed up `mkPreludeTyConUnique 23` slot soon for a new `bigNatTyConKey` (as part of the #9281 effort) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 14:49:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 14:49:12 -0000 Subject: [GHC] #9451: Incorrect optimizations involving negative zero Message-ID: <046.95a4616ae1eb14be12b30b2f5b71e7bf@haskell.org> #9451: Incorrect optimizations involving negative zero -------------------------------------+------------------------------------- Reporter: manzyuk | 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: -------------------------------------+------------------------------------- The program {{{#!hs main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0 where negativeZero = negate 0.0 }}} outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core: {{{ -- GHC 7.6.3 Main.main2 = case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ { GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char); GHC.Types.True -> case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0) of wild2_aK6 { __DEFAULT -> GHC.Float.$w$sshowSignedFloat GHC.Float.$fShowDouble_$sshowFloat GHC.Show.shows26 wild2_aK6 (GHC.Types.[] @ GHC.Types.Char) } } }}} {{{ -- GHC 7.8.3 Main.main2 = case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] { __DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char); 0.0 -> case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT -> GHC.Float.$w$sshowSignedFloat GHC.Float.$fShowDouble_$sshowFloat GHC.Show.shows27 wild2_a1NU (GHC.Types.[] @ GHC.Types.Char) } } }}} I don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 16:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 16:36:43 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.32256fb4dc57fa20fb89565252a5e529@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): When trying to do floating in the desugarer I arrived at a point where I need evidence bindings to desugar. For instance, when encountering the expression `static return :: Ref (a -> IO a)`, the desugarer tries to float `return` as {{{ Main.static:0 :: forall a_azE. a_azE -> GHC.Types.IO a_azE Main.static:0 = \ (@ a_azE) -> GHC.Base.return @ GHC.Types.IO $dMonad_azG @ a_azE }}} where `$dMonad_azG` is a variable carrying the `Monad IO` dictionary. As `$dMonad_azG` is not in scope the above code is rejected by the Core Lint pass. When floating is done in the typechecker, the binding of `$dMonad_azG` is produced by `simplifyInfer` in `checkStaticValues` at the place where the floated bindings for static forms are assembled. Further down the processing, desugaring inserts this evidence binding as a core `let` binding in the rhs of `static:0`, subsequently inlined to yield something like: {{{ Main.static:0 :: forall a_azE. a_azE -> GHC.Types.IO a_azE Main.static:0 = \ (@ a_azE) -> GHC.Base.return @ GHC.Types.IO GHC.Base.$fMonadIO @ a_azE }}} Now, to do floating in the desugarer, it looks like evidence bindings need to be communicated to the place in the desugarer (I presume `dsExpr`) where the floating should be implemented. Would there be a preferred way to do it? I couldn't find precedents of similar needs in the ghc code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 18:36:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 18:36:11 -0000 Subject: [GHC] #9451: Incorrect optimizations involving negative zero In-Reply-To: <046.95a4616ae1eb14be12b30b2f5b71e7bf@haskell.org> References: <046.95a4616ae1eb14be12b30b2f5b71e7bf@haskell.org> Message-ID: <061.ed4e40bc3d63d968ff678fa5a199c69c@haskell.org> #9451: Incorrect optimizations involving negative zero -------------------------------------+------------------------------------- Reporter: manzyuk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | 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 rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #9238, but interesting to know that it is a regression from 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 18:37:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 18:37:37 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.96fed861ab374354580a5a57584357e1@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 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: #7858, #9451 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #7858 => #7858, #9451 * milestone: => 7.8.4 Comment: And #9451. Ideally we would fix this for 7.8.4 since it is a regression from 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 19:02:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 19:02:27 -0000 Subject: [GHC] #9452: freeGroup: block size is zero Message-ID: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> #9452: freeGroup: block size is zero ----------------------------------+---------------------------------------- Reporter: scott.sadler | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- I'm trying to extract pixels from OpenGL and read them into a ForeignPointer, but getting a segfault while doing a peek operation. The fault is on line 240 in `peekArray`. It crashes in different ways depending on the arguments to `readPixelArray`. with `readPixelArray 0 0 100 100`: {{{ (lldb) run Process 26467 launched: '/Users/scott/Code/grids/dist/build/grids/grids' (x86_64) 0x00000001015b3010 Process 26467 stopped * thread #1: tid = 0x23d3cc, 0x0000000100621ead grids`evacuate + 157, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff8) frame #0: 0x0000000100621ead grids`evacuate + 157 grids`evacuate + 157: -> 0x100621ead: movl -0x8(%r12), %esi 0x100621eb2: leal -0x1(%rsi), %ecx 0x100621eb5: cmpl $0x3b, %ecx 0x100621eb8: ja 0x1006222a9 ; evacuate + 1177 }}} with `readPixelArray 0 0 200 200`: (lldb) run Process 26647 launched: '/Users/scott/Code/grids/dist/build/grids/grids' (x86_64) 0x00000001095d8010 grids: internal error: freeGroup: block size is zero (GHC version 7.8.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Process 26647 stopped * thread #1: tid = 0x23f4d4, 0x00007fff8b2cc866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main- thread', stop reason = signal SIGABRT frame #0: 0x00007fff8b2cc866 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill + 10: -> 0x7fff8b2cc866: jae 0x7fff8b2cc870 ; __pthread_kill + 20 0x7fff8b2cc868: movq %rax, %rdi 0x7fff8b2cc86b: jmpq 0x7fff8b2c9175 ; cerror_nocancel 0x7fff8b2cc870: ret The "freeGroup: block size is zero" message appears in the second output. I'm stumped trying to debug this one. I didn't get as far as trying to go backwards in time debugging it because of lack of familiarity with lldb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 19:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 19:11:13 -0000 Subject: [GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux In-Reply-To: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> References: <047.8ff8936a8082bdb3e0c2617996031a2e@haskell.org> Message-ID: <062.e71474ffee4bde7fd7f1bbf7f66fcbb0@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: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8976 Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by rwbarton): Thanks for testing. Hmm, how odd. This happens before dll-split gets build, so it seems that it must be due to an unrelated change in HEAD; but I can't find what that change could be. Hopefully the LLVM mangler patch will be backported to 7.8 soon, and then you can try with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 19:18:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 19:18:41 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.d180ab11f977f9b25de7014d4a3b8f1f@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): What's the milestone for this patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 19:34:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 19:34:51 -0000 Subject: [GHC] #9452: freeGroup: block size is zero In-Reply-To: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> References: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> Message-ID: <066.e3521ac64411d1053657cfbad0a3e45b@haskell.org> #9452: freeGroup: block size is zero -------------------------------------+------------------------------------- Reporter: | Owner: simonmar scott.sadler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): According to my reading of https://www.opengl.org/sdk/docs/man2/xhtml/glReadPixels.xml, `glReadPixels` with `format=GL_RGBA` and `type=GL_UNSIGNED_INT` will write one unsigned int per channel per pixel, so it will overwrite the array you allocated by a factor of 4. Looks like it is overwriting some GC information as `evacuate` and `freeGroup` are GC-related functions (not surprising that the GC would run during `peekArray`, as it has to allocate a large list). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 19:56:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 19:56:09 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken Message-ID: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgenerics_example/: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 20:29:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 20:29:25 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.f50579dff09f595b0cee82008560d417@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): **Problem:** as mentioned in the description, `Any`-the-type-family does not admit a `Typeable` instance. `Any`-the-datatype does. We need a `Typeable` instance because `Any` is used as a proxy for type variables when invoking `typeOf` on a value at a polymorphic type. **Context:** rank1dynamic generalizes `Data.Typeable` to handle rank-1 polymorphic types, not just monotypes. This is useful because in Cloud Haskell one often expects a polymorphic function to be received. Any incoming function must be tagged with a representation of its type in order to compare it the expected type. rank1dynamic currently only handles types with quantified type variables of kind `*`. To make it handle types with quantified type variables of arbitrary kind, we instantiate all type variables with `Any` in order to get a monotype, for which we can get a `typeOf` can give us a runtime representation. Example: {{{ data Dict c = c => Dict return' :: Dict (Monad m) -> a -> m a type ANY1 = Any type ANY2 = Any Any tyreturn' = typeOf (return' :: Dict (Monad ANY1) -> ANY2) }}} this only works if `Any` has a `Typeable` instance. Otherwise, the `Typeable` constraint for the type written down in the signature cannot be satisfied. **Possible solutions:** 1. Hardcode a `Typeable` instance for `Any` in GHC, even though it is now a type family. 1. Reintroduce a new `Any`-the-datatype in the compiler, under a different name, and use that in `rank1dynamic` instead of GHC HEAD's `Any `-the-type-family. Restrict this `Any`-the-datatype to inhabit only open kinds, not closed kinds, in order to avoid #9380, #9097. 1. Same as previous solution, but don't bother with any restrictions on what kinds are inhabited. Consider this new `Any`-the-datatype *really- unsafe-use-at-your-own-risks*. Its use in rank1dynamic would be fine for types with no occurrences of closed type families. It would not work ok for more exotic types, but I don't think that would be a big deal in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 20:49:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 20:49:17 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.7052a0f99d6f91b57abafcd278ae68fe@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): or 4. come up with an alternative way to support Typeable instances on polymorphic values? right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 20:58:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 20:58:34 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.09a63702ed40ce5353787a96464734e2@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:21 carter]: > or 4. come up with an alternative way to support Typeable instances on polymorphic values? right? Yes, absolutely. No idea how to articulate that solution further though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 21:19:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 21:19:48 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.8160cd70fd8901c38fb3f076246ef8c0@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki Comment: crokeea: I think it's done already; see comment:3. The ticket is still open only because Iavor may add a Note to explain the stuff in subsequent comments. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 21:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 21:22:09 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.e5f813aa4b4f16960f2f6a998c67b7d9@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | 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: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => dreixel Comment: Assigning to Pedro: would you care to comment/fix? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 21:26:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 21:26:15 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.bb0bfda0320899deb4f3a347a92623ae@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry, but I still don't understand the problem. Why exactly do you need a `Typeable` instance for types involving `Any`? In the example you give in "Context", you could perfectly well declare your own data type `MyAny` and use it instead of `Any`. Can you give a more complete example that shows why it's essential to have a `Typeable` instance for GHC's `Any`? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 21:40:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 21:40:07 -0000 Subject: [GHC] #9452: freeGroup: block size is zero In-Reply-To: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> References: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> Message-ID: <066.fe7ab058b7e9ac242424ab82f96fbe1c@haskell.org> #9452: freeGroup: block size is zero -------------------------------------+------------------------------------- Reporter: | Owner: simonmar scott.sadler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by scott.sadler): Yep, spot on! Thanks for the help, will close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 22:08:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 22:08:57 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.e3c0b0b6ba49ee41e678439a3345f0a3@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): But `MyAny`'s kind must end in `-> *`. This would limit the ability of poly-kinded higher-rank functions in Cloud Haskell, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 22:27:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 22:27:48 -0000 Subject: [GHC] #9452: freeGroup: block size is zero In-Reply-To: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> References: <051.054ab9a43cdd10a95da6084296f6d9ff@haskell.org> Message-ID: <066.c280f588b4d4f9b768770cba4c8e6d5d@haskell.org> #9452: freeGroup: block size is zero -------------------------------------+------------------------------------- Reporter: | Owner: simonmar scott.sadler | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: invalid | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 22:28:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 22:28:27 -0000 Subject: [GHC] #9450: GHC instantiates Data instances before checking hs-boot files In-Reply-To: <044.e97ab0330439b82d1df8c46c46f1a39d@haskell.org> References: <044.e97ab0330439b82d1df8c46c46f1a39d@haskell.org> Message-ID: <059.6b9c5e2ae04af16503560257eeafab2a@haskell.org> #9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: boot,deriving Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): This is awkward. GHC currently typechecks the source file, and then compares with the hs-boot file for consistency. And indeed, we ''must'' do that, because until we have done at least some typechecking we don't have any type from the source file to compare with those in the hs-boot file. I suppose that the difficulty is that the very act of typechecking the source file leads to an unexpected situation and a crash. I have not worked out the details. I'm not sure how to solve this. One route (which seems like the right one) might be to make the check ''whenever extending the type environment''; that is, as soon as we have got to the point of adding a data type T, or function f, to the environment, at that moment check compatibility. Probably not too hard, but a bit fiddly, and I'm definitely not going to have time to do it soon. And yet it's bad that GHC actually crashes. It should never do that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 17 22:43:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Aug 2014 22:43:28 -0000 Subject: [GHC] #9454: Unregisterized builds failing due to multiple uniques assigned to same FastString Message-ID: <045.da312330814d158945afffd5d67b3478@haskell.org> #9454: Unregisterized builds failing due to multiple uniques assigned to same FastString -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- When compiling with `--enable-unregisterised`, we get this failure: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key conta_4P4 dHnD3A89EkvERxmaFmd -hide-all-packages -i -ilibraries/containers/. -ilibraries/containers/dist-install /build -ilibraries/containers/dist-install/build/autogen -Ilibraries/containers/dist-install/build -Il ibraries/containers/dist-install/build/autogen -Ilibraries/containers/include -optP-include -optPli braries/containers/dist-install/build/autogen/cabal_macros.h -package-key array_H3W2D8UaI9TKGEhUuQHax2 -package-key base_DiPQ1siqG3SBjHauL3L03p -package-key deeps_L0rJEVU1Zgn8x0Qs5aTOsU -package-key ghcpr _BE58KUgBe9ELCsPXiJ1Q2r -O2 -Wall -XHaskell98 -XRoleAnnotations -O2 -no- user-package-db -rtsopts -odir libraries/containers/dist-install/build -hidir libraries/containers /dist-install/build -stubdir libraries/containers/dist-install/build -dynamic-too -c libraries/containers/./Data/StrictPair.hs -o libraries/containers/dist-install/build/Data/StrictPair.o -dyno libraries/containers/dist-install/bui ld/Data/StrictPair.dyn_o : unknown package: deepseq-1.3.0.2 }}} The reason why GHC is unable to find the package is because, as it turns out, the Unique that was used to store the key in a map is different from the Unique associated with the FastString that we're doing the lookup with. The bug only shows up with ghc-stage1 is compiled with optimizations. Bisecting revealed that this commit was to blame: {{{ commit 66218d15b7c27a4a38992003bd761f60bae84b1f Author: Edward Z. Yang Date: Fri Jul 18 14:48:47 2014 +0100 Package keys (for linking/type equality) separated from package IDs. }}} However, looking at the commit, there is nothing that would obviously cause this problem, so maybe it is tickling a preexisting bug. Bisection script: {{{ #!/bin/sh make clean git submodule update perl boot ./configure --enable-unregisterised make -j11 libraries/containers/dist-install/build/Data/StrictPair.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 00:29:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 00:29:54 -0000 Subject: [GHC] #9448: Clarify documentation of a quasi-quoter form In-Reply-To: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> References: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> Message-ID: <059.6b30714b3b25531d4eb0ad063f42f616@haskell.org> #9448: Clarify documentation of a quasi-quoter form -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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 rwbarton): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 01:20:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 01:20:42 -0000 Subject: [GHC] #9455: Data.Data documentation has a broken link Message-ID: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> #9455: Data.Data documentation has a broken link -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: documentation | 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: -------------------------------------+------------------------------------- The link to URL http://www.cs.vu.nl/boilerplate/ does not go to a meaningful page. The page is an empty page. The link is in the documentation here: http://hackage.haskell.org/package/base-4.7.0.1/docs /Data-Data.html#t:DataType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 06:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 06:15:27 -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.37a70607bd7941b2885bb72f79d30004@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Based on the structure of the code, I think we probably want a rewrite rule for `tail $ scanl' ...` to avoid adding the first element instead of trying to take it off later, which doesn't work so well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:03:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:03:41 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.e2addce0ea6f77b950606e5116a1306c@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): * If I declare `MyAny`, then as goldfire pointed out, it can only have a kind of the form `-> *`. As it is, if rank1dynamic uses a datatype of fixed kind, as for `MyAny`, then I will need many, many of those datatypes, defined a priori. To handle multiple type variables, as in the example given previously, I need a family `MyAny1`, `MyAny2`, `MyAny3`, etc... Along an orthogonal dimension, to handle multiple kinds, I will need multiple `MyAny`s, i.e. `MyAny1_s`, `MyAny1_ss`, `MyAny2_s`, `MyAny2_ss`, etc (where `MyAny_s` is of kind `*`, `MyAny_ss` is o f kind `* -> *`, etc). And even with that proliferation of datatypes, I still wouldn't be able to handle type variables of user-defined kind, or even of `Constraint` kind. The beauty of the `Any` type in this use case is that because it inhabits all kinds, I can use `Any` to instantiate the first type variable, `Any Any` to instantiate the second, `Any Any Any` to instantiate the third, etc. Moreover, I can still use those no matter the kinds of the type variables. I only need a single datatype, to serve as a proxy for an arbitrary number of type variables, each of arbitrary kind. * A larger end-to-end example will take a little while to write, but I'll try to do so tonight. At this point, if it can clarify things, let's just say that any message that gets sent over the wire needs an accompanying `TypeRep` of its type in order for the receiver to make sense of the payload. Sometimes the payload is a function, and sometimes that function is polymorphic and can be called by the receiver at any argument type. We can't represent polymorphic types directly, so for a function of type `forall a. a -> a`, we send the `TypeRep` for `Any -> Any` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:05:04 -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.4c25b0d81604a078a61d8b1dca385e65@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: | -------------------------------------+------------------------------------- Comment (by hvr): For the record: the commit-range 12644c3c0216edfcff33266f4f250e0c52004352 to 535b37cbb5a11dd4c9d8260d1d00f4cb993af0e9 seems to be what was merged to address this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:14:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:14:38 -0000 Subject: [GHC] #9455: Data.Data documentation has a broken link In-Reply-To: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> References: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> Message-ID: <060.e28b267cfd43117f103636cc2c1dea9c@haskell.org> #9455: Data.Data documentation has a broken link -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: documentation 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 hvr): I guess we should simply link to http://research.microsoft.com/en- us/um/people/simonpj/papers/hmap/ instead, which I assume will be more stable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:21:50 -0000 Subject: [GHC] #9448: Clarify documentation of a quasi-quoter form In-Reply-To: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> References: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> Message-ID: <059.70eba9d6fbc2b1f669011e6409ba3f04@haskell.org> #9448: Clarify documentation of a quasi-quoter form -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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 Simon Peyton Jones ): In [changeset:"2aabda1a836a5250c3176e8559a10479214a55f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2aabda1a836a5250c3176e8559a10479214a55f6" Fix quasi-quoter documentation (#9448) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:21:50 -0000 Subject: [GHC] #9455: Data.Data documentation has a broken link In-Reply-To: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> References: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> Message-ID: <060.b30d61a8d7892686891917e5dd482aea@haskell.org> #9455: Data.Data documentation has a broken link -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: documentation 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 Simon Peyton Jones ): In [changeset:"daef885a8a9866af5b486d21a1940d4e3d93d9d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="daef885a8a9866af5b486d21a1940d4e3d93d9d0" Fix broken link in Data.Data to SYB home page (Trac #9455) Ralf Laemmel's page has disappeared, so I made it point to the Haskell Wiki page instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:22:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:22:44 -0000 Subject: [GHC] #9448: Clarify documentation of a quasi-quoter form In-Reply-To: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> References: <044.fa13e1ef4398ef4a75c97df102555fd0@haskell.org> Message-ID: <059.0b9530583740f6ddf039357c19276a04@haskell.org> #9448: Clarify documentation of a quasi-quoter form -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 Documentation | Keywords: Resolution: fixed | 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 simonpj): * status: patch => closed * resolution: => fixed Comment: Good point. Thank you for the patch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:23:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:23:40 -0000 Subject: [GHC] #9455: Data.Data documentation has a broken link In-Reply-To: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> References: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> Message-ID: <060.a6c6a573adb30b9a225d60f37c8baa5c@haskell.org> #9455: Data.Data documentation has a broken link -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: documentation 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 simonpj): * status: new => closed * resolution: => fixed Comment: Done, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 08:52:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 08:52:08 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.32fda2ddd402c965368066c287960f4c@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Note: you already have multiple "MyAnys" `Any` inhabits all kinds, so `Any :: Nat -> *` is also a perfectly cromulent type it can inhabit, allowing you to use `Any 0, Any 1, Any 2`... This means having `Any` doesn't just punch a "one extra distinguishable member of every kind" sized hole in the sanity of the typesystem but rather it creates an infinite family of such holes. I abused that for a while in Hask to create 'evil' targets for compositions of functors to other kinds, etc. but the status quo comes at a terrible terrible price. We can no longer reason that a closed kind has a fixed set of inhabitants. `Bool` is currently inhabited by `True`, `False`, and `Any 'FileNotFound` as distinguishable inhabitants along with an infinite set of other such exotic beasts. This implementation strategy is also very leaky. You have to be very careful, as it is possible to subvert the use of this sort of mechanism very easily (and accidentally) in the presence of functional dependencies when you go to apply it in situations where one of the arguments is a GADT or functional dependency, argument to a class, etc. This can lead to straight up segfaults, not just local type strangeness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 09:00:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 09:00:29 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.a19e056a70da3e73b998628d140e69d3@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): If the issue is getting a type rep for a polymorphic type, let's address ''that'' problem directly, rather than hack a solution (by representing `forall a. a->a` as `Any -> Any`) in which the hack itself has pervasive negative consequences. See also #7015, where this same issue arises. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 09:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 09:09:14 -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.419f75374c6e586823cea6db8c1daa91@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string -------------------------------------+------------------------------------- Reporter: mjo | Owner: Ashley Yakeley Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.8.2 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Ashley Yakeley): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD for time-1.5. {{{ Prelude Data.Time> parseTime defaultTimeLocale "%Q " " " :: Maybe LocalTime Just 1970-01-01 00:00:00 Prelude Data.Time> parseTime defaultTimeLocale "%k" " 8" :: Maybe LocalTime Just 1970-01-01 08:00:00 Prelude Data.Time> parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime Just 1970-01-01 00:15:00 UTC Prelude Data.Time> parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime Just 1970-01-01 00:15:00 UTC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 09:53:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 09:53:20 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.730b17c8ec9fe7bbc7ba66f4cee76163@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): To be clear, as I have said before, I'm not arguing for reverting back to the status quo that we have in GHC 7.8. It's pretty clear that we want to avoid having (an infinite number of) exotic inhabitants of kinds that are intended to be closed (and often with a finite number of inhabitants). As I see it if the old `Any`-as-datatype is revived under a different name, without imposing any restrictions on what kinds it inhabits (i.e. only open kinds), it would have to be in an `Unsafe.*` module, and only brought in scope in some very clearly delineated modules. At least in the case of Cloud Haskell, there is no reason why the user needs to even know of its existence - it's use can be contained, "behind the scenes". That may well still be unsatisfactory. simonpj: I'm all for a better solution that is not a hack like `rank1dynamic` is, but do you have any ideas for how generating `TypeRep`s for polymorphic types might work? `rank1dynamic` has the merit of existing today, and the reason we're seeking to extend it is precisely to help with #7015 without having to rewrite some of the internals of `distributed- process`. Of course, if we do understand how to get type reps for polymorphic types, Facundo and I are happy to volunteer some time to do the rewriting. So again, there are 4 possible solutions here. I don't know which one would be best, but it would be nice to support a better story for Cloud Haskell, which already has a number of users, while still keeping to a minimal impact on the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 12:48:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 12:48:46 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs Message-ID: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This program is rejected by GHC 7.8.2: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} With the following type error: {{{ foo.hs:15:11: Couldn't match type ?a0? with ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by the type signature for g :: a -> a at foo.hs:14:12-17 Expected type: a -> a Actual type: a0 -> a0 Relevant bindings include g :: a -> a (bound at foo.hs:15:7) f :: a0 -> a0 (bound at foo.hs:10:7) In the expression: f In an equation for ?g?: g = f }}} Perplexingly, however, you can get it to compile either by adding a type signature to f: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f :: x -> x f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by disabling the GADTs extension: {{{ {-# LANGUAGE ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by getting rid of the asTypeOf: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x in x g :: a -> a g = f return () }}} Or by defining ?box? differently: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do let box = Box () let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} And perhaps some other factors that I haven't tested yet. It appears to me that all of these should be valid programs. Real world source: https://github.com/andygill/io- reactive/blob/master/Control/Concurrent/Reactive.hs It happens here due to the usage of (putMVar box ret), which makes the function requestit in line 77 not as polymorphic as it should be, unless you add a type signature. The putMVar serves the same role as the `asTypeOf` in my smaller example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 12:56:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 12:56:41 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.85fe4c78a2d04e1af141fefcd7beb5dd@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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: | -------------------------------------+------------------------------------- Description changed by haasn: Old description: > This program is rejected by GHC 7.8.2: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > With the following type error: > > {{{ > foo.hs:15:11: > Couldn't match type ?a0? with ?a? > because type variable ?a? would escape its scope > This (rigid, skolem) type variable is bound by > the type signature for g :: a -> a > at foo.hs:14:12-17 > Expected type: a -> a > Actual type: a0 -> a0 > Relevant bindings include > g :: a -> a (bound at foo.hs:15:7) > f :: a0 -> a0 (bound at foo.hs:10:7) > In the expression: f > In an equation for ?g?: g = f > }}} > > Perplexingly, however, you can get it to compile either by adding a type > signature to f: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f :: x -> x > f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > Or by disabling the GADTs extension: > > {{{ > {-# LANGUAGE ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > Or by getting rid of the asTypeOf: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x > in x > > g :: a -> a > g = f > > return () > }}} > > Or by defining ?box? differently: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > let box = Box () > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > And perhaps some other factors that I haven't tested yet. > > It appears to me that all of these should be valid programs. > > Real world source: https://github.com/andygill/io- > reactive/blob/master/Control/Concurrent/Reactive.hs > > It happens here due to the usage of (putMVar box ret), which makes the > function requestit in line 77 not as polymorphic as it should be, unless > you add a type signature. The putMVar serves the same role as the > `asTypeOf` in my smaller example. New description: This program is rejected by GHC 7.8.2: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} With the following type error: {{{ foo.hs:15:11: Couldn't match type ?a0? with ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by the type signature for g :: a -> a at foo.hs:14:12-17 Expected type: a -> a Actual type: a0 -> a0 Relevant bindings include g :: a -> a (bound at foo.hs:15:7) f :: a0 -> a0 (bound at foo.hs:10:7) In the expression: f In an equation for ?g?: g = f }}} Perplexingly, however, you can get it to compile either by adding a type signature to f: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f :: x -> x f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by disabling the GADTs extension: {{{ {-# LANGUAGE ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by getting rid of the asTypeOf: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x in x g :: a -> a g = f return () }}} Or by defining ?box? differently: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do let box = Box () let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} And perhaps some other factors that I haven't tested yet. It appears to me that all of these should be valid programs. Real world source: https://github.com/andygill/io- reactive/blob/master/Control/Concurrent/Reactive.hs It happens here due to the usage of ?writeChan chan $ Done ret?, which makes the function requestit in line 77 not as polymorphic as it should be, unless you add a type signature. The putMVar serves the same role as the `asTypeOf` in my smaller example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 12:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 12:57:17 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.7a2e989a770ff7928c3222798a591bb8@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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: | -------------------------------------+------------------------------------- Description changed by haasn: Old description: > This program is rejected by GHC 7.8.2: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > With the following type error: > > {{{ > foo.hs:15:11: > Couldn't match type ?a0? with ?a? > because type variable ?a? would escape its scope > This (rigid, skolem) type variable is bound by > the type signature for g :: a -> a > at foo.hs:14:12-17 > Expected type: a -> a > Actual type: a0 -> a0 > Relevant bindings include > g :: a -> a (bound at foo.hs:15:7) > f :: a0 -> a0 (bound at foo.hs:10:7) > In the expression: f > In an equation for ?g?: g = f > }}} > > Perplexingly, however, you can get it to compile either by adding a type > signature to f: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f :: x -> x > f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > Or by disabling the GADTs extension: > > {{{ > {-# LANGUAGE ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > Or by getting rid of the asTypeOf: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > box <- return (Box ()) > > let f x = > let _ = Box x > in x > > g :: a -> a > g = f > > return () > }}} > > Or by defining ?box? differently: > > {{{ > {-# LANGUAGE GADTs, ExistentialQuantification #-} > module Foo where > > data Box = forall a. Box a > > foo :: Monad m => m () > foo = do > let box = Box () > > let f x = > let _ = Box x `asTypeOf` box > in x > > g :: a -> a > g = f > > return () > }}} > > And perhaps some other factors that I haven't tested yet. > > It appears to me that all of these should be valid programs. > > Real world source: https://github.com/andygill/io- > reactive/blob/master/Control/Concurrent/Reactive.hs > > It happens here due to the usage of ?writeChan chan $ Done ret?, which > makes the function requestit in line 77 not as polymorphic as it should > be, unless you add a type signature. The putMVar serves the same role as > the `asTypeOf` in my smaller example. New description: This program is rejected by GHC 7.8.2: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} With the following type error: {{{ foo.hs:15:11: Couldn't match type ?a0? with ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by the type signature for g :: a -> a at foo.hs:14:12-17 Expected type: a -> a Actual type: a0 -> a0 Relevant bindings include g :: a -> a (bound at foo.hs:15:7) f :: a0 -> a0 (bound at foo.hs:10:7) In the expression: f In an equation for ?g?: g = f }}} Perplexingly, however, you can get it to compile either by adding a type signature to f: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f :: x -> x f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by disabling the GADTs extension: {{{ {-# LANGUAGE ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} Or by getting rid of the asTypeOf: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do box <- return (Box ()) let f x = let _ = Box x in x g :: a -> a g = f return () }}} Or by defining ?box? differently: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module Foo where data Box = forall a. Box a foo :: Monad m => m () foo = do let box = Box () let f x = let _ = Box x `asTypeOf` box in x g :: a -> a g = f return () }}} And perhaps some other factors that I haven't tested yet. It appears to me that all of these should be valid programs. Real world source: https://github.com/andygill/io- reactive/blob/master/Control/Concurrent/Reactive.hs It happens here due to the usage of ?writeChan chan $ Req fun ret?, which makes the function requestit in line 77 not as polymorphic as it should be, unless you add a type signature. The putMVar serves the same role as the `asTypeOf` in my smaller example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 12:57:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 12:57:55 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.c0093fbad63cb0555239cc82c31d6ea9@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 bernalex): 7.8.3 rejects it as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 14:51:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 14:51:26 -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.bb0a2d2be7162f4da061435f76ba4170@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: | 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 sweirich): * cc: sweirich@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 16:23:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 16:23:45 -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.5277e549e4c2b0e0baaa0e6b104a91d7@haskell.org> #9150: libraries/time: parseTime barfs on leading space in format string -------------------------------------+------------------------------------- Reporter: mjo | Owner: Ashley Yakeley Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.8.2 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mjo): Replying to [comment:4 Ashley Yakeley]: > Fixed in HEAD for time-1.5. > Awesome, thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 16:28:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 16:28:44 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.360f60b0286ddd889eb8c81626bdfd50@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Comment (by simonpj): I've added a comment or two to the Phab link. Austin: please commit. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 22:55:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 22:55:38 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.31677fc3b4e29837afd459cff4268c07@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 rwbarton): This is all expected behavior?for some value of "expected"! See https://www.haskell.org/ghc/docs/latest/html/users_guide/other-type- extensions.html#mono-local-binds. Your original program does not typecheck because - the `GADTs` language flag implies `MonoLocalBinds` - `f` does not have a user-supplied type signature - `f` cannot be floated to top-level because it refers to `box`, and... - `box` cannot be floated to top-level either because it is not bound by a `let` and therefore the type of `f` is not generalized, and so it cannot be used polymorphically by `g`. Your four other programs each differ in one of these four features. Granted, this is all not very obvious; do you have any suggestion for a better error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 18 23:24:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Aug 2014 23:24:43 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.8b94f7d5136d9c37b97193d84aeb62c4@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 haasn): It would be great if the error message could somehow mention that this type signature was less polymorphic than it could be, and that perhaps the user wants to add NoMonoLocalBinds or an explicit type signature. Is that a case that can be detected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 00:05:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 00:05:14 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.b5b0a4d683f9c9281f0932297673c496@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 rwbarton): (I noticed the GADTs section of the User's Guide was out of date regarding the flags turned on by `-XGADTs`, fixed in b287bc9bd0afaa26fcd3fe53a49bf86deeb868d8.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 00:37:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 00:37:25 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.77e79a8a7ed92899be2358555a442675@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 02:13:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 02:13:41 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.05deab101846c1fa49f0a827a0dcedf8@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Comment (by afarmer): I've updated the Phab patch with a more explicit comment, as requested. It should be ready to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 03:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 03:15:29 -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.bdd1db490f38b587219af0428f0ab03a@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: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T8832 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"a72614c40186521da7ba090b102436e61a80b7a7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a72614c40186521da7ba090b102436e61a80b7a7" Make T8832 operative on 32-bit systems (#8832) (Also, the 'extra_clean' was unnecessary.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 03:17:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 03:17:22 -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.936e7fed29854833a5739874dc317fab@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: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T8832 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Is this what you had in mind, Simon? Without the `#ifdef`s the grep output on a 32-bit system would contain uniques, so I couldn't just add a `.stdout-ws-32` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 03:54:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 03:54:17 -0000 Subject: [GHC] #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode Message-ID: <047.1a08fdc9c8e87e7e04f09b9f3fcedabf@haskell.org> #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | 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: -------------------------------------+------------------------------------- I would like to be able to do {{{ config_args='--target=i386-unknown-linux --with-gcc=i386-unknown-linux- gcc' ./validate }}} to validate a 32-bit GHC on a 64-bit Linux system. (I don't know why I have to specify `--with-gcc` in addition to `--target`; an unrelated mystery.) However `validate` sets `-Werror` and the C code that `hsc2hs` generates in cross-compilation mode is not always warning-free, e.g., {{{ Files.hsc: In function ?_hsc2hs_test?: Files.hsc:81:14: error: variable ?test_array? set but not used [-Werror =unused-but-set-variable] cc1: all warnings being treated as errors }}} so `hsc2hs` draws incorrect conclusions from its tests. Either the `hsc2hs`-generated C code should be made (and kept) warning- free, or perhaps `hsc2hs` should append `-Wwarn` to the options that it passes to the C compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:33:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:33:52 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.85267e24f233239930bdb81fb1baefe1@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch 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:D156 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5d5655e9911dba10088b66421e98165c6cb8176e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d5655e9911dba10088b66421e98165c6cb8176e" Fix three problems with occurrence analysis on case alternatives. Summary: 1. Respect condition (a) in Note [Binder swap] 2. Respect condition (b) in Note [Binder swap] 3. Return usage of any coercion variables in binder swap Fixes T9440 Test Plan: See #9440 Reviewers: simonpj, austin Reviewed By: simonpj, austin Subscribers: simonpj, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D156 GHC Trac Issues: #9440 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:33:53 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.fbf79dfc11d428a34ac5f58fe1cac6de@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d9a20573f473cc7389004470999b8a318aa6b3f2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d9a20573f473cc7389004470999b8a318aa6b3f2" Make Prelude.signum handle -0.0 correctly (#7858) Summary: Make the `Float` and `Double` implementations of `signum` handle -0.0 correctly per IEEE-754. This, together with "Make Prelude.abs handle -0.0 correctly (#7858)", fixes Trac #7858. Depends on D145 Signed-off-by: Alexander Berntsen Test Plan: signum of (-0.0) should be (-0.0) not 0.0. Test program: main = putStrLn $ p ++ " " ++ n where f = show . signum p = f (-0.0 :: Double) n = f (0.0 :: Double) Reviewers: ekmett, hvr, rwbarton, austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D148 GHC Trac Issues: #7858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:33:53 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.a7f05764dc17c03da782974864e4bbcb@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6f6ee6eaa348b1a4815190c4d526d5c81c264fa7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6f6ee6eaa348b1a4815190c4d526d5c81c264fa7" Make Prelude.abs handle -0.0 correctly (#7858) Summary: Make the `Float` and `Double` implementations of `abs` handle -0.0 correctly per IEEE-754. abs (-0.0::Float) and abs (-0.0::Double) previously returned -0.0, when they should return 0.0. This patch fixes this. Signed-off-by: Alexander Berntsen Test Plan: abs (-0.0::Double) should = 0.0 instead of (-0.0) Reviewers: ekmett, hvr, austin, rwbarton Reviewed By: austin, rwbarton Subscribers: phaskell, trofi, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D145 GHC Trac Issues: #7858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:34:04 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.8fd51705e20482ef4408c182c159e03c@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"bbd031134a571c1020945b2548e3fc4795b5047a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bbd031134a571c1020945b2548e3fc4795b5047a" Bug #9439: Ensure that stage 0 compiler isn't affected Summary: Bug #9439 will cause miscompilation of GHC's LLVM backend. Here we ensure that an affected compiler isn't used to bootstrap. Test Plan: Attempt to bootstrap GHC with an affected stage 0 compiler. Reviewers: rwbarton, austin Reviewed By: austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D159 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:34:05 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.53be24ccc9fd1dc7c6ec82b17b9bc7eb@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 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0138110125400581dc9872dedfcb21bd50b372f1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0138110125400581dc9872dedfcb21bd50b372f1" Implement -rdynamic in Linux and Windows/MinGW32. Summary: In Linux, it is a synonym for -optl -rdynamic. In Windows, it is a synonym for -optl -export-all-symbols. Test Plan: validate Reviewers: simonmar, austin Reviewed By: simonmar, austin Subscribers: mboes, phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D102 GHC Trac Issues: #9381 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:34:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:34:05 -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.d34c97d9366149231f353f0ecf308f3c@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 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d2f01000ac07678b971743ebf1650837aad19b9f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d2f01000ac07678b971743ebf1650837aad19b9f" Have the RTS linker search symbols in the originating windows binary. Summary: In initLinker, this patch adds the handle of the module corresponding to the program binary to the list of DLL handles that lookupSymbol uses to search for symbols. Test Plan: validate Reviewers: simonmar, austin Reviewed By: simonmar, austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D103 GHC Trac Issues: #9382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:42:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:42:35 -0000 Subject: [GHC] #9458: 3 Keys To Building Muscle Mass Message-ID: <050.469d1bd5594da883a771ba51ef95aeff@haskell.org> #9458: 3 Keys To Building Muscle Mass -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Learning how to bod musculus aggregation is the foremost intellection on the minds of trillions of group who effort with gaining metric and expanding strength. [http://gainmusclesup.com/ Xtreme Nitro] If you've proved many nowadays to develop tough general and had soft or no success, there are trey canonical principles you penury to know. Soggy unit lifting done right, caliber nutrition, and decent interruption are the threesome important elements that testament create you the good results when you solon a muscle structure programme. Intelligent body builders and coefficient lifters bed proverbial these principles for ages. By incorporating these caudate programme, you will greatly growth your chances of move your goals.The most effective way to develop contractor body is to amount the strength of your workout package and eat the rightish foods in the sect amounts. There are whatsoever acerose guidelines you can uprise to forbear you acquire how to build strength aggregation and service you touch your goals.If you are sedate roughly acquisition how to increase ruffian body, you should eat a minimum of one bacteriologist of protein for apiece thump of bodyweight every day. Catalyst builds yob and the grandness of intense competent amounts on a regular bas http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 04:47:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 04:47:39 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.daee97abea0df9186bbde519ece955a7@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): It doesn't appear to be in 7.8.2. I haven't tried 7.8.3, but I'd rather not upgrade if it's not in there yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 05:50:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 05:50:15 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.4f344e745215dfb0ddaa8b3272e70f86@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: The nofib results look generally good, if I'm reading them right. It appears that with regard to allocations, the biggest benefits are to kahan (-7.8%), gamteb (-4.1%), and scs (-1.4%). The loser, for some reason, seems to be constraints (+3.6%). I don't have much faith in my (good- looking) timing measurements?the results look ... very wonky. I'm hoping maybe someone who's better at such things can try to measure those properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 06:09:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 06:09:02 -0000 Subject: [GHC] #9459: Bulk Up Muscle And Gain Weight Thro Message-ID: <050.d7a063c82c56ce3f3a00d724c2a5b67a@haskell.org> #9459: Bulk Up Muscle And Gain Weight Thro -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- f you essential to cognize how to gain coefficient and volume up yob, then be embattled to revised few of your ideas on what fasting real is. It is not honorable a matter of eating fewer in order to lose metric, but also of feeding to advantage weight. And what you eat is not necessarily beverage bar, but it could be! [http://gainmusclesup.com/ Xtreme Nitro] There is no disagreement between losing unit and gaining unit other than the quantity of travail you spread out, or, to put it many scientifically, how umpteen calories you color. Galore grouping don't consider in kilocalorie reckoning, but something has to be counted to express the force you decide in and that you use up in workout. Whether it is calories or any opposite sprightliness activity doesn't concern, so I testament birdsong them calories.If you eat author calories that you use in exercising, you put on weight. If you eat little calories than you use in practice you decline weight. If you poorness to decline unit then do the latter, and do the previous if you poorness to obtain unit. There is not deed absent from that base equation, irrespective of how you anticipate your liveliness intake and activity, or whether you eat sausages and an Atkins fast, or lettuce and a leporid diet, or even brownness cake on a drinkable cover diet. It makes absolutely no conflict. It is direct in suffragist!So eat you http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 06:41:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 06:41:23 -0000 Subject: [GHC] #9460: Muscle Buiding Foods - Eat Your Way To Large Muscles Message-ID: <050.d624479be5162f22c79aec45a51fe3cd@haskell.org> #9460: Muscle Buiding Foods - Eat Your Way To Large Muscles -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- You soul to form certain you're feeding all the justness strength antiquity foods if your end is to make more contractor. It's echt: Vindicatory as there are positive kinds of foods hit it gentle for you to earn unwanted weight, there are also predictable foods that gift improve you climb bully. [http://gainmusclesup.com/ Xtreme Nitro] You poorness to cogitate up abstinence matter and all that scrap content that tastes so healthful but is so bad for you. It's instance to pay good attending to what you eat and attain careful you're ingestion your embody wholesome foods.There are scientists and dr. who human pyramidical out that musculus edifice is 85% diet and 15% upbringing, and if you expect some it, they've got a component.We somebody 24 hours in a day, and you are probably leaving to pay one or maybe two hours at the most working out. The set of the reading you're either unerect, feeding, and doing whatsoever you do at occupation. Since you pass author instance uptake than you do excavation out, it makes faculty to see what you eat.When you're active to habitus any strength, protein is the most influential portion in contractor antiquity foods. You'll deed this in matter suchlike chickenhearted, foodstuff, seek, and red meat. They are packed whole of accelerator, which you condition for healthiness.Added crucial factor in bully construction foods is fat. No, not the charitable of fat you attain in soiled cooked foods. We're talking nigh angelical, spontaneous fats launch in pod butter, steak, and foodstuff. http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 06:47:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 06:47:17 -0000 Subject: [GHC] #9461: Nofib test defines its own copies of inits and tails Message-ID: <045.d8b677d7dcca7cb64f7b61a03099ebfe@haskell.org> #9461: Nofib test defines its own copies of inits and tails -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- nofib/real/rx/src/Stuff.hs defines its own copies of inits and tails, preventing improvements to the library definitions from affecting its performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 06:52:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 06:52:58 -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.7076b550ec4f03bc382d7f8bef8ddf71@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T8832 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: That's great thank you. (Do you know about `-dsuppress-uniques`? But in any case, it's probably best to suppress the 64-bit test on a 32-bit system.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 06:59:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 06:59:27 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.3eb468ecb903ec62e47c46fa820ff49f@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: ? => 7.10.1 Comment: I don't think it was ever merged onto the 7.8 branch. It's an API change, which we don't usually merge because patch releases aren't supposed to change the API, only fix bugs. So you'll have to wait for 7.10 I'm afraid. Keeping this open, though, pending Iavor's `Note`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 07:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 07:00:43 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.f2972f11fc978ebb96a6b324c288004c@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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 simonpj): That looks helpful. But allocation probably should never go up. Do you know why it does so in constraints? I use `-ticky` a lot to track down these kind of things. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 07:10:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 07:10:56 -0000 Subject: [GHC] #9461: Nofib test defines its own copies of inits and tails In-Reply-To: <045.d8b677d7dcca7cb64f7b61a03099ebfe@haskell.org> References: <045.d8b677d7dcca7cb64f7b61a03099ebfe@haskell.org> Message-ID: <060.50b5d26f6ebb78b8384ec7bd74de0915@haskell.org> #9461: Nofib test defines its own copies of inits and tails -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: NoFib | Version: 7.8.3 benchmark suite | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Maybe so, but the point about nofib is that it is the real user code offered by real users. We are not free to change it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 07:14:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 07:14:11 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.69bc8c6a7fcd30f15ff08b80a415db65@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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:4 simonpj]: > That looks helpful. But allocation probably should never go up. Do you know why it does so in constraints? > > I use `-ticky` a lot to track down these kind of things. > > Simon I don't know how to use `-ticky` yet. How would I get nofib compiled with that? My best guess about constraints is that it's all about the evil spirit in the machine, by which I mean the inliner. One phenomenon I saw in some of my little tests was that inlining thresholds make things rather less compositional than one might like. That is, if `f x = ... g ...` and `g y = ... h ...`, then inlining `h` can make `g` "too big", so then `g` won't be inlined in `f` unless someone leans on the compiler to do so. My bet is that something that calls reverse is not being inlined as a result, and therefore some other optimization opportunity is missed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 07:24:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 07:24:18 -0000 Subject: [GHC] #9462: Are You Making These 5 Muscle Building Mistakes? Message-ID: <050.865fbe0923fe728e82a2fb13535a7e38@haskell.org> #9462: Are You Making These 5 Muscle Building Mistakes? -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- So some group rightful go through the motions with their workouts. They get into the abuse of viewing up at the gym day after day and mindlessly go through their subroutine. You can go into the gym on any presented day and see for yourself that the vast age of members gift not bonk any workout writing or any way of safekeeping rail of their develop? [http://gainmusclesup.com/ Xtreme Nitro] For a lot of these people going to the gym vindicatory becomes a strain of their mixer sentence. Now I agree that this tradition is a lot better then ornament out at the anaesthetic pub. But the measure you drop in the gym could be a lot author bearing and prove in structure a lot much sinew.What gets plumbed gets reinforced. All it takes is soft bit of example mentation out where you requisite to go and then create a drawing of proceeding on how you are deed to get there. Or get an tough equipage to provide you create an proceedings intend. The old speech "imperfectness to project, is preparation to miscarry" is oftentimes overused, but it is 100% veracious, especially when it comes to bodybuilding.===Sign 4 - Performing Too Often Exercise: OvertrainingWorking out too more is honourable as prejudicial to construction rowdy as doing cipher at all. Once you workout you soul to elasticity your body instant to ameliorate and discolour finished pause. A vernacular error that group variety is intellection that they gift get http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 07:24:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 07:24:28 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.93a49f759181d5f4cd5f30fb0b39bb85@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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 simonpj): Ticky ticky: https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky Inlining: yes, it's difficult. Would love solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 08:23:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 08:23:26 -0000 Subject: [GHC] #9463: How To Gain Muscle On A Budget Message-ID: <050.b779c0a37e810e202851bbeb1c9b1a71@haskell.org> #9463: How To Gain Muscle On A Budget -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Gaining hooligan and edifice a fit body doesn't possess to cost a condition. In fact, it's really loose to study how to rise yobo on a budget. One of the things I bang most around metric preparation and musclebuilding is that no concern how umteen diametric "revolutionary supplements" that develop out or what personage endorses the newest showy workout equipment, antiquity muscle testament always pass soul when you have it peltate old fashioned timeless equipment equal barbells and dumbbells. [http://gainmusclesup.com/ Xtreme Nitro] So if you are worried that it module outgo you a lot of money to turn bully then go aweigh and stroke that whim rightmost out the pane. Here is all you necessary to make character roughneck right equal anybody added: a gym membership, many accelerator solid, a multi-vitamin, a pad of stuff and pencil, active collection, groceries that fit the specialized spirit of gaining sinew, and a saintlike state workout programme. Now, let's fortuity and see how we can get it as inexpensive as workable:Gym Membership: This present probably be your most dear assets. Withal, do whatsoever explore in your area and chances are you will judge a pretty honorable plenty. Commonly there are gyms in most areas where you can get a membership under cardinal dollars a period and many of them such cheaper. A fast face observe is although this may be pricey for several, it is shaft couturier having a honourable gym that has everything you requisite to workout. Cite that you are disagreeable to gain musculus and disagreeable to crosscut by not having all the weights, benches, and equipment you necessary instrument never support couturier http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 08:28:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 08:28:30 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.c2d80f05e0d7b619bf14058214940202@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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): Reid is, as ever, spot on. I think it might not be hard for the error message to say {{{ foo.hs:15:11: Couldn't match type ?a0? with ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by the type signature for g :: a -> a at foo.hs:14:12-17 Expected type: a -> a Actual type: a0 -> a0 Relevant bindings include g :: a -> a (bound at foo.hs:15:7) f :: a0 -> a0 (bound at foo.hs:10:7) NB: let-bound f is monomorphic because of MonoLocalBinds <------------ In the expression: f In an equation for ?g?: g = f }}} That is, annotate the "relevant bindings" that we did not attempt to generalise. It would be much harder to annotate only bindings that ''would'' generalise, but didn't. For example {{{ foo v = do let f x = v g :: a -> a g = f }}} Here `f` can't be generalised regardless of `MonoLocalBinds` because it mentions `v`. The other difficulty is that adding `-XNoMonoLocalBinds` if you have `-XGADTs` is extremely dodgy. (It should probably elicit a stern warning, although it does not at the moment.) So implicitly encouraging people to switch it off rather than fix the program properly is a bad idea. Perhaps the message should say: {{{ NB: Let-bound f was not generalised Possible solution: give it a type signature }}} Users, what do you think. Check out the [http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type- extensions.html#typing-binds user manual section] (7.13.9.3). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 08:31:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 08:31:30 -0000 Subject: [GHC] #9455: Data.Data documentation has a broken link In-Reply-To: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> References: <045.92c02cdd0e91a586b793c6bc837e763b@haskell.org> Message-ID: <060.033160fb6419c4bafa5882f29b56dd2f@haskell.org> #9455: Data.Data documentation has a broken link -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: | Version: 7.8.2 libraries/base | Keywords: documentation 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: | -------------------------------------+------------------------------------- Comment (by dreixel): For reference, this is the old page: http://web.archive.org/web/20080622204226/http://www.cs.vu.nl/boilerplate/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 08:37:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 08:37:30 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.83d6f27670918b7e78ab9228ba2229ee@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | 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: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Yes; certainly if the way the compiler nests sums in the automatic derivation of `Generic` instances changes, or if the user is giving their own instances, there is no guarantee that the serialisation outcome is the same. I could perhaps add a note to the example in the manual to highlight the fact that it doesn't try to work across different versions of the compiler. Updating the example to deal with different nestings would be overkill, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 08:57:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 08:57:47 -0000 Subject: [GHC] #9441: CSE should deal with letrec (was: Merge identical top-level expressions following simplification when it is safe to do so) In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.20fc0f6777a7f2b193b5741ecec082b0@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | 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 simonpj): The common subexpression elimination pass (CSE.lhs) doesn't deal with letrec at all, at the moment. We'd like this transformation: {{{ Rec { x = ...x... } ... Rec { y = ...y... } ===> rec { x = ...x... } ... NonRec { y = x } }}} Extending CSE to do this would be a good goal. It would make a good little project. Need to think about how to deal with mutual recursion too! (Or maybe dealing with a singleton `Rec` would do as a start.) The current CSE transform is quite compact and elegeant; I would regret some very hairy new code, and I hope there is a nice elegant way. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 09:07:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 09:07:42 -0000 Subject: [GHC] #9464: Muscle Building To Lose Weight Message-ID: <050.ae7bc5861eab4639f5531c164b0e87a8@haskell.org> #9464: Muscle Building To Lose Weight -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Yobo business also helps a cause in the walk of metric diminution and coefficient deprivation is significant because more symptoms and ailments withdraw situate because of over coefficient or fatness. Diseases suchlike somebody, diabetes, hyper status, depression and galore statesman occurs because of over weight or blubber. [http://gainmusclesup.com/ Xtreme Nitro] Therefore, yobbo building is a way to retrograde weight, since a person with the aim to acquire muscle paves a way to worsen unit, too. Hooligan construction requires a person to vary some healthy and fit habits in his or her spiritedness. Prototypic and foremost, a soul should thought a diet or excrete an eating drawing, which should be counterpoised and allow all the matter groups. For monition, it is territory that the diet hump substance components suchlike accelerator, sugar, vitamins, nutrients, minerals, fat etc.Yobbo construction is a promulgation or procedure that requires a being to eat levelheaded and eat the correct quantity and lineament of substance. The most grievous nutrient components required by a cause to survive in his or her embody is accelerator and supermolecule. Protein is the most influential component, because protein is the antiquity fence of all the contractor and the principal foodstuff of ruffian antiquity.Accelerator has the section titled radical acids that is the most primal piece of yobo building. Thus, a cause to make hooligan moldiness get the intake of matter lucullan in protein proportionality, for admonition, gallinacean products equal volaille and egg, river and yoghurt, meat and search. And especially, if the meat is from a run tune, it'll get less fat proportion. http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 09:29:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 09:29:38 -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.03337613e903beeb25e236bb0dbf26f5@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T8832 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:15 Reid Barton ]: > In [changeset:"a72614c40186521da7ba090b102436e61a80b7a7/ghc"]: > {{{ > #!CommitTicketReference repository="ghc" revision="a72614c40186521da7ba090b102436e61a80b7a7" > Make T8832 operative on 32-bit systems (#8832) > > (Also, the 'extra_clean' was unnecessary.) > }}} Btw, now that I saw that commit, I've seen other testcases making use of the pre-defined `SIZEOF_HSWORD` (and there's also `WORD_SIZE_IN_BITS`) CPP symbol to test for wordsize. Would that have worked as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:02:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:02:47 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r Message-ID: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: sed | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Building hour) | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- configure fails (but does not stop) as follows: {{{ : checking version of ghc... 7.8.3 checking whether bootstrap compiler is affected by bug 9439... yes checking build system type... x86_64-apple-darwin14.0.0 checking host system type... x86_64-apple-darwin14.0.0 checking target system type... x86_64-apple-darwin14.0.0 Build platform inferred as: x86_64-apple-darwin Host platform inferred as: x86_64-apple-darwin Target platform inferred as: x86_64-apple-darwin GHC build : x86_64-apple-darwin GHC host : x86_64-apple-darwin GHC target : x86_64-apple-darwin configure: Building in-tree ghc-pwd sed: illegal option -- r usage: sed script [-Ealn] [-i extension] [file ...] sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...] }}} The gnu sed manual page says -r --regexp-extended Use extended regular expressions rather than basic regular expressions. Extended regexps are those that egrep accepts; they can be clearer because they usually have less backslashes, but are a GNU extension and hence scripts that use them are not portable. See Extended regular expressions. So the fix is, presumably to add \ before () in the configure script at {{{ sed -r 's/(^| )([^ ])/\1-optl\2/g' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:04:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:04:21 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.0d92bbf30a854e90e9dbf50b26436937@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by jrp: Old description: > configure fails (but does not stop) as follows: > {{{ > : > checking version of ghc... 7.8.3 > checking whether bootstrap compiler is affected by bug 9439... yes > checking build system type... x86_64-apple-darwin14.0.0 > checking host system type... x86_64-apple-darwin14.0.0 > checking target system type... x86_64-apple-darwin14.0.0 > Build platform inferred as: x86_64-apple-darwin > Host platform inferred as: x86_64-apple-darwin > Target platform inferred as: x86_64-apple-darwin > GHC build : x86_64-apple-darwin > GHC host : x86_64-apple-darwin > GHC target : x86_64-apple-darwin > configure: Building in-tree ghc-pwd > sed: illegal option -- r > usage: sed script [-Ealn] [-i extension] [file ...] > sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... > [file ...] > }}} > > The gnu sed manual page says > > -r > --regexp-extended > Use extended regular expressions rather than basic regular expressions. > Extended regexps are those that egrep accepts; they can be clearer > because they usually have less backslashes, but are a GNU extension and > hence scripts that use them are not portable. See Extended regular > expressions. > > So the fix is, presumably to add \ before () in the configure script at > {{{ > sed -r 's/(^| )([^ ])/\1-optl\2/g' > }}} New description: configure fails (but does not stop) as follows: {{{ : checking version of ghc... 7.8.3 checking whether bootstrap compiler is affected by bug 9439... yes checking build system type... x86_64-apple-darwin14.0.0 checking host system type... x86_64-apple-darwin14.0.0 checking target system type... x86_64-apple-darwin14.0.0 Build platform inferred as: x86_64-apple-darwin Host platform inferred as: x86_64-apple-darwin Target platform inferred as: x86_64-apple-darwin GHC build : x86_64-apple-darwin GHC host : x86_64-apple-darwin GHC target : x86_64-apple-darwin configure: Building in-tree ghc-pwd sed: illegal option -- r usage: sed script [-Ealn] [-i extension] [file ...] sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...] }}} The gnu sed manual page says -r --regexp-extended Use extended regular expressions rather than basic regular expressions. Extended regexps are those that egrep accepts; they can be clearer because they usually have less backslashes, but are a GNU extension and hence scripts that use them are not portable. See Extended regular expressions. So the fix is, presumably to remove the -r and add \ before () in the configure script at {{{ sed -r 's/(^| )([^ ])/\1-optl\2/g' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:10:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:10:51 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.590d4030b9421a1df09426931c7eced8@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: Component: Compiler | Architecture: Unknown/Multiple Resolution: fixed | 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 thoughtpolice): * status: patch => closed * resolution: => fixed * related: 7015 => #7015 * milestone: => 7.10.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:11:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:11:12 -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.77a88aab29cd4bf0599847819c6afa57@haskell.org> #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | 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 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 Tue Aug 19 10:29:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:29:54 -0000 Subject: [GHC] #7379: rangeTest test fails on Windows In-Reply-To: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> References: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> Message-ID: <059.d4b45816d45ee11d677fd533841552a6@haskell.org> #7379: rangeTest test fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/random | 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 thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:30:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:30:34 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.1d7d97f70ea56fe8abbee4249b76007c@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:31:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:31:43 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.b91d8e019891e1345a819519275ab7ed@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------+------------------------------------- Reporter: | Owner: jimenezrick | Status: upstream Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: POSIX | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:32:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:32:27 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.a9f989339638ce62371cf1f3efda65e6@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | 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: Phab:D42 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: hvr, ekmett (added) * differential: => Phab:D42 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:32:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:32:53 -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.9818204f4feb1a28ef6f24663e279026@haskell.org> #7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------- Reporter: | Owner: ekmett ryantrinkle | Status: upstream Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:34:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:34:52 -0000 Subject: [GHC] #9440: Buggy binder swap in occurrence analysis In-Reply-To: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> References: <046.5bfdcc6aace3edbf3fe2e85ebcf5bf8b@haskell.org> Message-ID: <061.878bda3c821401c8e7689eaa6d458e2f@haskell.org> #9440: Buggy binder swap in occurrence analysis -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 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: Phab:D156 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:35:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:35:51 -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.9fda1d4c4300c414d5b16d960b262a5f@haskell.org> #9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: | Keywords: libraries/base | 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: Phab:D81 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: This was merged in 9a7440c0dc038a19432e86923ac30ade7bcea3e7/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:36:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:36:42 -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.c5745fb264af9d5f5ced3f960057e4cb@haskell.org> #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature | Status: upstream request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: libraries | Keywords: stm (other) | 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 thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:37:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:37:36 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.73178d209194bfa76aaf9fb999417fe1@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------- Reporter: | Owner: ekmett novadenizen | Status: upstream Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:37:45 -0000 Subject: [GHC] #9466: Muscle Failure, Get In Shape By Failing First. Message-ID: <050.85f8e1a63fc8433997c011fc92407068@haskell.org> #9466: Muscle Failure, Get In Shape By Failing First. -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- If you necessary to tug your person potential when it comes to fitness, then you forward screw to change. This way actuation your muscles to the bushel where they cannot speak to accomplish an take decently. To accomplish sinew unfortunate, your high rep should arrive the stop where you could not do other recap without refrain. When finished decently, this write of workout can dramatically change your posture and ruffian gains. [http://gainmusclesup.com/ Xtreme Nitro] Musculus nonstarter has embellish the key component in the "piping grade upbringing" weightlifting motility. Low the squeaky degree breeding (or HIT) interpret, improvident but wicked workouts are prescribed for peak gains in stripped abstraction. Additionally, due to the sweat exerted in an HIT workout that goes to roughneck insolvency, someone involved in such a suitability programme give demand greater amounts of break and retrieval. During this deed, muscles make been strained during take.Muscle insolvency has proven exceptionally salutary for people illustrious as "plosive gainers." Velar gainers are individuals who undergo it nearly intolerable to process their contractor body due to their bodies' born motility to be skinny. Yet, everyone can help from incorporating strength loser exercises into their fitness subprogram. Why? Because contractor poet fat. (solon on that later). http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:38:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:38:33 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.80f3977ec1457b17bee5c581915c969a@haskell.org> #8943: Add System.Process.createPipe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature | Status: upstream request | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/process | 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 thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:38:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:38:54 -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.8f8a312f276a87f9f650a042c5c6039e@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: | overflow 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 => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:42:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:42:00 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.7bda49243ce3fa97aa34715747de9c6c@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: Comments: For the check on line 1444 for `ver == 32`, why is this last? If we only issue a warning, then it will simply match on `isAvxEnabled dflags` (line 1443) and still pass in the right arguments. Would it not be more correct to have this branch checked first and instead turn off AVX completely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:45:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:45:10 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.8cccc1f058b90054082f1fc5adf0acb4@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: infoneeded 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: @Joachim: is this patchset still in limbo? If there's no measurable performance impact, but it improves code and doesn't hurt performance, I don't see why you cannot merge it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:47:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:47:12 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.e25a5ca9e213177eb5dab164b453c7ca@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: infoneeded Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: I haven't followed this whole thread, but it seems like there are still a few questions to answer before merging anything; if anyone would like to summarize the discussion here and take ownership of this to get a full patch in, that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:48:59 -0000 Subject: [GHC] #9154: Links to Cabal documentation from the user guide are broken In-Reply-To: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> References: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> Message-ID: <061.a8911df874d85da6d21a8add5b71f1bf@haskell.org> #9154: Links to Cabal documentation from the user guide are broken -------------------------------------+------------------------------------ Reporter: etrepum | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | 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 Austin Seipp ): In [changeset:"e3c3586d717e6f1eb0e80f25b29a16de6c0f6d5c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e3c3586d717e6f1eb0e80f25b29a16de6c0f6d5c" Use absolute links to Cabal docs from the GHC users guide (#9154) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:49:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:49:25 -0000 Subject: [GHC] #9154: Links to Cabal documentation from the user guide are broken In-Reply-To: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> References: <046.fc5b062da2d1072804978e34c9b0db1c@haskell.org> Message-ID: <061.86f7af6508ab072a6509b3225fa5dae9@haskell.org> #9154: Links to Cabal documentation from the user guide are broken -------------------------------------+------------------------------------- Reporter: etrepum | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 Documentation | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:49:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:49:54 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.7565bba1c434f2ee55d6bbb7c7508719@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------+------------------------------------- Reporter: | Owner: jimenezrick | Status: upstream Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: POSIX | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I've created a PR out that at https://github.com/haskell/unix/pull/7 so it doesn't get lost -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:50:25 -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.2f127dd2729d6b7a6a388018b4cfec6d@haskell.org> #9126: -ddump-to-file in TcRnMonad.lhs -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: GregWeber Type: bug | Status: infoneeded 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: #8624 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * related: => #8624 Comment: Do let me know if you have any updates on this and put it back to `patch` status, please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:53:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:53:33 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.e8d320305180394b177f1127c6813d9e@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: Pedro, any updates on this? Should Ollie's changes be merged or do you have some other plans here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:55:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:55:13 -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.79346b4cfbe746e638df77a94221c78d@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 Austin Seipp ): In [changeset:"89f5f314e32c3e80c71f4b3dcc8835ae74d7d57f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89f5f314e32c3e80c71f4b3dcc8835ae74d7d57f" Explain how to clone GitHub forks. Ticket #8379. This information is mirrored at: http://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingaGHCrepositoryfromGitHub Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:55:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:55:36 -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.0ad421c0683c835cb73b01fd588b23a9@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | 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 thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:58:25 -0000 Subject: [GHC] #9119: Additional symbols for XUnicodeSyntax In-Reply-To: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> References: <050.28440c83618567b1dad67ee6e8f31e47@haskell.org> Message-ID: <065.997f7a1d154f592fe32f5827fd966a32@haskell.org> #9119: Additional symbols for XUnicodeSyntax -------------------------------------+------------------------------------- Reporter: | Owner: spacekitteh | Status: infoneeded Type: feature | Milestone: request | Version: 7.8.2 Priority: normal | Keywords: unicode Component: Compiler | Architecture: Unknown/Multiple (Parser) | Difficulty: Easy (less than 1 Resolution: | hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: Yes, this is really going to need a somewhat wider discussion first, I think. @spacekitteh would you be willing to email `ghc-devs`, asking about this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 10:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 10:59:47 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.93c6cc66faffa249d6adfb2cfce69ef7@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | 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 dreixel): Sorry for the delay; it's still in my to do list. His changes can be merged, though; perhaps it's best to do that earlier rather than later, to avoid conflicts. But please keep the ticket open; I'll close it once I make sure that the datatypes generated when deriving `Generic` have `Typeable` instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:10:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:10:38 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.017b22e87f660b26743f596b0a42a2d7@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/haskell2010 | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1042 Type of failure: Incorrect | result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: (Bumping this ticket out of `patch` status since there's quite a bit of discussion about it.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:11:36 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing In-Reply-To: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> References: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> Message-ID: <059.e1064209555d926a1b8f3d2d32fbf6cb@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: row, column, Operating System: Unknown/Multiple | major, Ix Type of failure: Documentation | Architecture: Unknown/Multiple bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2fc22949e30eab9f751be90e788ebb2b56f1b132/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2fc22949e30eab9f751be90e788ebb2b56f1b132" Mention that `Data.Ix` uses row-major indexing This addresses Trac #8712 by simply mentioning row-major indexing, thereby removing any ambiguity. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:12:09 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing In-Reply-To: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> References: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> Message-ID: <059.736445f8b7b6a74cc1cdfb01433a981a@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: row, column, Resolution: fixed | major, Ix 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:12:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:12:18 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing In-Reply-To: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> References: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> Message-ID: <059.420aee6e6e7a57f767d8bdb8a09cb151@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: row, column, Resolution: fixed | major, Ix 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:13:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:13:53 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.5b1cf3d7d08f7cb7cfc9ef25b09636d2@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: @monoidal: What's the status here? Would you like to merge these patches yourself and get the changed merged to Judah's repository for this to land? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:16:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:16:22 -0000 Subject: [GHC] #8988: Documentation build fails if GHCi is unavailable In-Reply-To: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> References: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> Message-ID: <062.ea31b31d4edadd964a7b336ffb025f77@haskell.org> #8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1 (Type checker) | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | 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: I believe this was already fixed in d996a1bb4db84727fbf1a8e9461a032e04e544e7 - sorry we missed your patch, Colin! Please re-open if this doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:17:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:17:03 -0000 Subject: [GHC] #9467: How To Harness The Power Of The Net To Fin Message-ID: <050.90474d0cd731e811eac6319d38f68599@haskell.org> #9467: How To Harness The Power Of The Net To Fin -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Creation Yobo Cars are a passion for so umpteen group. Sometimes we straight eliminate it our jobs, for others it is a concern abstraction pastime.Then, there are the fans, they are the group who like creation strength cars and actually go to car shows to see them, but aren't truly interested in artist musculus cars for merchantability. T[http://gainmusclesup.com/ Xtreme Nitro]here are also many group who issue in between, they know the cars, and change owned a unify creation bully cars for understanding, but also feature otherwise hobbies. At the top of the aggregation, there's the aficionado. The guy who is in jazz with creation muscle cars, he collects them, he activity on them and he drives them and belike has whatsoever classic yobbo cars for loving virtually their creation roughneck cars as they are with lifespan. They soul e'er owned them, and may hold a few artist sinew cars for merchandising at any period. He's the guy who module pay a lot but loves to uncovering his ducky artist roughneck car for sale cheap. He may someone another progression, but musculus cars are his desire. Greedy collectors hear to locate creation muscle cars from numerous sources, the important one state the cyberspace lately. Since everyone likes to vaporing nigh a quality mass, the web has beautify the most touristed spot to reach artist yobbo cars for selling.More collectors somebody contacts, but lots of fill do not, the net levels the activity ground.There are va http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:19:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:19:34 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.6536ff803e8ba5caf90104cd111467e2@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: I'm +1 on this feature, but I personally think this should have a command line flag, for example, `ghc --interactive --local-ghci-history`, perhaps with a short-name if one is sensible. This is much easier for users to understand (e.g. they can look at `man ghc` to find it) I think. Please also update the documentation and I'll get to this - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:22:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:22:37 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.083705978c8a1191beff1d92e9fe76f9@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: feature | Milestone: 7.10.1 request | Version: 7.6.3 Priority: normal | Keywords: Component: GHCi | 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 thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: Please: - Add documentation about the new parameter. - Add some tests. - Squash these commits together (easier to land all at once.) Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:24:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:24:25 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.121fb9c715d506ebd9a6057702214c5b@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: AlainODea Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Easy (less than 1 time crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: kgardas (added) * status: patch => infoneeded Comment: Karel, can you please look at this? I'm generally fine with this change, but you're the Solaris master, so you should probably check as well so it doesn't break something for you... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:30:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:30:49 -0000 Subject: [GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test In-Reply-To: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> References: <048.3d999da96b34c75e9d81c2f7d5eea5ef@haskell.org> Message-ID: <063.9d1d36bfd6604a8ef6fb7206361c2a51@haskell.org> #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(profthreaded) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: AlainODea Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Easy (less than 1 time crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): Hi, sorry Alain for not including your patch. I've not known about it and fixed this in the same way in {{{ commit cc3717597597c031dd8402c443f40f76d432c044 Author: Karel Gardas Date: Mon Jul 28 07:49:12 2014 -0500 do not link with -lrt on Solaris for threaded way Summary: This patch removes linking with rt library on Solaris for threaded way. The reason is simple it casuses few ffi related tests failures and also is not needed anymore. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D95 }}} so feel free to close this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:40:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:40:15 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.3aa0cbab556cb631c02d111a08ee3665@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: infoneeded 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 nomeata): > @Joachim: is this patchset still in limbo? If there's no measurable performance impact, but it improves code and doesn't hurt performance, I don't see why you cannot merge it. Compiler code complexity would be one reason to not merge it. Other than that I mostly forgot about this... and so I?m not sure about the completeness of my work (and it needs more comments, as always). I?ll eventually return to it, but without high priority. Just leave it assigned to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:41:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:41:20 -0000 Subject: [GHC] #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 Message-ID: <042.f56238c72b33ff97328342ddd5955833@haskell.org> #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When running this example program: https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess-problem- hs I get the error: {{{ % ghc --make -O forkProcess-problem.hs -threaded && ./forkProcess-problem +RTS -N8 [1 of 1] Compiling Main ( forkProcess-problem.hs, forkProcess-problem.o ) Linking forkProcess-problem ... forkProcess-problem: internal error: resurrectThreads: thread blocked in a strange way: 10 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Also happens for GHC 7.6.3. My machines are Ubuntu 12.04 and 14.04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:41:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:41:35 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.34efc40a28c949c1a0e908d71a7a0788@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.7 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: I think we should re-post this to the list IMO if it saw any review. Would hvr/ekmett like to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:41:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:41:36 -0000 Subject: [GHC] #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 In-Reply-To: <042.f56238c72b33ff97328342ddd5955833@haskell.org> References: <042.f56238c72b33ff97328342ddd5955833@haskell.org> Message-ID: <057.d84ebf5acf40a947bf8a3cd19ee9a807@haskell.org> #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:45:35 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.04fbb7f0d47309507cd0d11a5588b28c@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -------------------------------------+------------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: I think this patch is OK, but what minimum version is `hw.logicalcpu` supported in? Perhaps instead it should simply try both: fall back to `hw.ncpu` if `hw.logicalcpu` fails. Could you make this change @kseo? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:47:22 -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.2829384f1426d74ddf6fce52422c5bcc@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: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"defc42e7dfdcc0685077ef3dc8bea6b80e2a66dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="defc42e7dfdcc0685077ef3dc8bea6b80e2a66dc" Add test case for #9046 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:48:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:48:39 -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.03319203ace7c9b823796c31c2ad862e@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: GHCi | 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: tests/ghci.debugger/scripts/print036| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => new * testcase: => tests/ghci.debugger/scripts/print036 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:48:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:48:47 -0000 Subject: [GHC] #9469: Learn The Foods That Build Muscle In Order Message-ID: <050.81a016d099f70b4912ef85d97c657095@haskell.org> #9469: Learn The Foods That Build Muscle In Order -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Prudish nutrition is an intact of a soundness promulgation fashioned to figure yobo bulk??but do you bonk the foods that body bully in prescript to win your desirable results? Do you undergo the magnitude that the various nutrients should be consumed in tell to get your to your goals? [http://gainmusclesup.com/ Xtreme Nitro] Here is a sampling recite of extraordinary foods to determine from that support the justice type and become of catalyst (20), carbohydrates (65 to 15%) based on the recommended regular divergence. (No, the percentages don't commute when you are structure yobo. The number is in the signaling of calories you spend.)Mention, it's always optimum to get the rectify portions of the nutrients you beggary straight from the matter you eat. Supplements transmute but are artificially manufactured in the eld of instances and refer the old song, "Ain't nada similar the realistic aim baby." To anatomy muscle magnitude, material your fast with these delicious options retributive to cant a few. "Proteins - put with egg whites, yellow, land, beans, fish much as river and scombroid. Steady city and venison are uppercase pro http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:57:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:57:02 -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.a4c9948e3c5b9386ad086ddfa0f09674@haskell.org> #7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------- Reporter: | Owner: ekmett ryantrinkle | Status: upstream Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Runtime | crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): The change makes sense to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:58:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:58:10 -0000 Subject: [GHC] #8156: amd64 + in-tree gmp build broken In-Reply-To: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> References: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> Message-ID: <059.00cbaaaafb66cc885c34b06f862f5182@haskell.org> #8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: #4022 #4366 #4374 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: OK, with `integer-gmp2` on the horizon (Phab:D82), these changes will need to be revisited, and we really should have a coherent discussion about what to do for the `in-tree` GMP. So I'm bumping this out of `patch` status since it still hasn't gone anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 11:58:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 11:58:58 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.61181bc7a5048bb7299d49ce30a107cf@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: ekmett (added) * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:00:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:00:00 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.a2380959c0a9f22da55d41bbddfbb27e@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:00:43 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.cba12072434536bc37713df6fd9c1e9c@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I think these should be filed at the new unix upstream, https://github.com/haskell/unix.git (Herbert can confirm if he wishes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:07:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:07:17 -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.71fd72318d1092f5c5e8d15f56b967f9@haskell.org> #7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------- Reporter: | Owner: ekmett ryantrinkle | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4218, 427 Type of failure: Runtime | crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: upstream => closed * resolution: => duplicate * related: => 4218, 427 Comment: Consolidating this with https://ghc.haskell.org/trac/ghc/ticket/4218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:07:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:07:43 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.16a1340c8f7aa79ba4bb09d8ead5c586@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------ Reporter: osa1 | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"806d823e757c73f77f03fdf2d1eba6a83b1e32e6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="806d823e757c73f77f03fdf2d1eba6a83b1e32e6" Correct checkStrictBinds for generalised type See Trac #9140. Auditors: simonpj Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:09:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:09:04 -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.d48297215dd72a037cc32a515ad457c1@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: ekmett Type: bug | Status: upstream Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * related: => 427, 7936 Comment: The change makes sense to me. I've closed out https://ghc.haskell.org/trac/ghc/ticket/7936, which was a duplicate of this issue to consolidate here (as this was the older bug report, but left https://ghc.haskell.org/trac/ghc/ticket/427 as it has a bit broader scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:09:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:09:49 -0000 Subject: [GHC] #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 In-Reply-To: <042.f56238c72b33ff97328342ddd5955833@haskell.org> References: <042.f56238c72b33ff97328342ddd5955833@haskell.org> Message-ID: <057.befb91935c0e303197ac195a75f21dd4@haskell.org> #9468: Internal error: resurrectThreads: thread blocked in a strange way: 10 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): {{{Constants.h}}} seems to suggest that the {{{10}}} is {{{BlockedOnCCall}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:09:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:09:55 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.b7eba8999a433309e174fb1405edf526@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): Major part of the dyson-libs.patch is not about unix module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:10:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:10:01 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.bb7ed7fb0a1f4cfb0334ca0cdd85dfc5@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------+------------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: sync-all 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 Austin Seipp ): In [changeset:"7012ed8515100b4947383e93b82dbff7a0aa835c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7012ed8515100b4947383e93b82dbff7a0aa835c" Check if file is present instead of directory Fixes #8886. Problem: any `sync-all` command that is run before the first succesfull `sync-all get` would trigger a false warning about an old `time` package being present. Cause: after cloning the ghc repository, the (empty) `libraries/time` directory is already present. Solution: check if the directory actually contains any of the `time` files. I picked the `LICENSE` file, since `boot` does so as well. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:10:27 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.df412a265d0469722dc8f0e886dba38d@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------- Reporter: osa1 | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, making sure Simon will audit it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:10:52 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.11477c0530736f454634ef515c8986e8@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: sync-all 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:11:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:11:03 -0000 Subject: [GHC] #8886: sync-all: END actions result in confusing error message In-Reply-To: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> References: <041.565e5cae6ef758af98091faf07b20c55@haskell.org> Message-ID: <056.01c52cd3a70fbf2c8b97b6bb47f6fa06@haskell.org> #8886: sync-all: END actions result in confusing error message -------------------------------------+------------------------------------- Reporter: fw | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: fixed | Keywords: sync-all 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:12:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:12:53 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.171b10bbb899e88d6694e50ebdbe267a@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/haskell2010 | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1042 Type of failure: Incorrect | result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): It seems worth polling the whole core libraries committee to achieve a judgment on this. I'll follow up there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:13:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:13:11 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.f3268c81a7f26c26af86ddd92944a18a@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------- Reporter: osa1 | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: tests/ghci/scripts/T9140 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * testcase: => tests/ghci/scripts/T9140 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:13:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:13:42 -0000 Subject: [GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) In-Reply-To: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> References: <044.20ec687237e6a721e0a67e453dd37b49@haskell.org> Message-ID: <059.24df768e803673a15fdb257d389aee94@haskell.org> #9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by scpmw): My reasoning was that if the user explicitly requests AVX using `-mavx`, it makes sense not to override it. After all, it is a relatively uncommon bug, and there might be ways to work around it for a given module. I might be overthinking this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:15:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:15:01 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.169aebe6d341ba3aeca42a2f705ec0a5@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | 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 haasn): My greatest concern with manually applying type signatures is that, as seen in my real world use case, adding an explicit type signature would require changing more than just that function, due to ScopedTypeVariables being needed. But, barring some way to tell GHC to explicitly ?generalize (just) this function?, and assuming that adding -XNoMonoLocalBinds when it would otherwise be implied is a Bad Thing, then I'd be content with the user just being told to generalize manually. I do think adding a big fat warning label about something not generalizing is important, because I personally did not even know this restriction existed - and I would not have guessed adding a type signature fixes anything because I was operating under the impression that GHC already infers the most general rank-1 type for things that are not on the top level. I believe a false positive for things that could not generalize either way is an acceptable trade-off, as long as the message is not *too* obnoxious. In this particular case, I believe a good error message could also mention the fact that the type variable ?a0? is forced to be monomorphic, which is ultimately why ?a? can't be matched with ?a0? (which seems counter- intuitive given just the first line of the error message), but perhaps mentioning that the binding for ?f :: a0 -> a0? is monomorphic would suffice. Up to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:16:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:16:32 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.364432b7d13904179c4fe72331e99250@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: @archblob - it seems this doesn't correcly apply to HEAD anymore. Would you mind rebasing the changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:28:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:28:14 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.62d3829d4b988feedf86525ce1ba6d7a@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 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 thoughtpolice): * status: patch => infoneeded * milestone: => 7.10.1 Comment: Iceland_Jack, now that HEAD requires 7.6 to bootstrap (527bcc41630918977c73584d99125ff164400695), I think this change can go in as long as the patch is changed to use an actual open type family. Would you mind doing that, and also submitting the patch in `git` format (Note you'll also need some minor changes like instances, see 93b1a43ebe8bf145b35e903966d4a62b7847f213)? That would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:32:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:32:36 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 Message-ID: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: 9468 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I run this program using `forkProcess` https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess-problem- hs in GHC 7.6.3 on Ubuntu 12.04 and 14.04 I get at 4 different issues. Three of them (1-3) crash the program, and happen only on some startups, the fourth one is the part for which I originally wrote this test case. 1. A segfault shortly after startup (probably in the GC) 2. {{{internal error: resurrectThreads: thread blocked in a strange way: 10}}} at startup 3. A glibc {{{corrupted double-linked list}}} shortly after startup 4. The {{{running, killing by SIGTERM}}} case inside my program Now come the details for each of them: 1. I managed to get a gdb trace of it (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-69468-3 -linux-segfault-gdb-txt) and also a trace with the {{{-debug}}} runtime (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3 -linux-debug-segfault-gdb-txt). They suggest that the segfault is in {{{evacuate()}}}, and the {{{-debug}}} one says it's in the {{{LOOKS_LIKE_CLOSURE_PTR}}} part. 2. This is the same as my newly reported #9468 and I have no clue what that's about. 3. This one happens very rarely; might be related to 1? 4. The problem here is the {{{Nothing}}} case: The child process didn't answer from the pipe, and that although it is still running, so it really should have answered. It seems that for every 20th fork or so, the child process just hangs. All files, error outputs and IRC logs are also collected in this gist: https://gist.github.com/nh2/0c68650b78b692e5f827 For getting issues (1-3), you have to run them multiple times in order to reproduce; if they appear, they will appear within the first second after startup. Which of the issue appears is dependent on how many {{{_FORKS}}} you set (with a high number like the default 80, you mostly get issue 2; set down to 8 to make the other ones more probably) and with how many {{{+RTS -N}}} threads you run. 2 and 4 are definitely present in 7.8.3 as well. For 1 and 3, it would be great if you could tell me whether these are known issues and are known to be fixed in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:36:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:36:02 -0000 Subject: [GHC] #9471: Rookie Guide On How To Buy A Muscle Message-ID: <050.e65d22c72d6058b7085d5a8dbf91dd3c@haskell.org> #9471: Rookie Guide On How To Buy A Muscle -------------------------------------+------------------------------------- Reporter: citynight05 | 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: -------------------------------------+------------------------------------- Now let's dig into determining what a logical value reach would be for a special car, and then go some deciding how to pay for it. Cost Limit: [http://gainmusclesup.com/ Xtreme Nitro] Determining the terms capableness on a stellar get, whether it be a yobo car, a hero jet, or a dishwasher generally comes feather to evaluating your individual financial position and determining what you can give. We'll act that you already understand that and leave put to determining the damage potentiality that the sort and mould car you are perception at may slope in.So righteous how do you truly ascertain the price comprise for a creation rowdy car? Somebody, you necessity to accept a face at what the activity thinks it's designer. Fair suchlike realistic demesne, yob car values are ascertained by what the marketplace thinks the cars are couturier, not by scheming the sum toll of all of their parts. The damage that group are currently paying for muscle cars is key. It's a subjective occurrence that relies on distribute and obligation. Also, dissimilar 99% of new cars, http://gainmusclesup.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:44:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:44:05 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.a8c85b1093e44a299c1d03628e16655e@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: 9468 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by nh2: Old description: > When I run this program using `forkProcess` > > https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess- > problem-hs > > in GHC 7.6.3 on Ubuntu 12.04 and 14.04 I get at 4 different issues. Three > of them (1-3) crash the program, and happen only on some startups, the > fourth one is the part for which I originally wrote this test case. > > 1. A segfault shortly after startup (probably in the GC) > 2. {{{internal error: resurrectThreads: thread blocked in a strange way: > 10}}} at startup > 3. A glibc {{{corrupted double-linked list}}} shortly after startup > 4. The {{{running, killing by SIGTERM}}} case inside my program > > Now come the details for each of them: > > 1. I managed to get a gdb trace of it > (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error- > ghc-7-69468-3-linux-segfault-gdb-txt) and also a trace with the > {{{-debug}}} runtime (https://gist.github.com/nh2/0c68650b78b692e5f827 > #file-error-ghc-7-6-3-linux-debug-segfault-gdb-txt). They suggest that > the segfault is in {{{evacuate()}}}, and the {{{-debug}}} one says it's > in the {{{LOOKS_LIKE_CLOSURE_PTR}}} part. > 2. This is the same as my newly reported #9468 and I have no clue what > that's about. > 3. This one happens very rarely; might be related to 1? > 4. The problem here is the {{{Nothing}}} case: The child process didn't > answer from the pipe, and that although it is still running, so it really > should have answered. It seems that for every 20th fork or so, the child > process just hangs. > > All files, error outputs and IRC logs are also collected in this gist: > https://gist.github.com/nh2/0c68650b78b692e5f827 > > For getting issues (1-3), you have to run them multiple times in order to > reproduce; if they appear, they will appear within the first second after > startup. Which of the issue appears is dependent on how many {{{_FORKS}}} > you set (with a high number like the default 80, you mostly get issue 2; > set down to 8 to make the other ones more probably) and with how many > {{{+RTS -N}}} threads you run. > > 2 and 4 are definitely present in 7.8.3 as well. > > For 1 and 3, it would be great if you could tell me whether these are > known issues and are known to be fixed in 7.8. New description: When I run this program using `forkProcess` https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess-problem- hs in GHC 7.6.3 on Ubuntu 12.04 and 14.04 I get at 4 different issues. Three of them (1-3) crash the program, and happen only on some startups, the fourth one is the part for which I originally wrote this test case. 1. A segfault shortly after startup (probably in the GC) 2. {{{internal error: resurrectThreads: thread blocked in a strange way: 10}}} at startup 3. A glibc {{{corrupted double-linked list}}} shortly after startup 4. The {{{running, killing by SIGTERM}}} case inside my program Now come the details for each of them: 1. I managed to get a gdb trace of it (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-69468-3 -linux-segfault-gdb-txt) and also a trace with the {{{-debug}}} runtime (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3 -linux-debug-segfault-gdb-txt). They suggest that the segfault is in {{{evacuate()}}}, and the {{{-debug}}} one says it's in the {{{LOOKS_LIKE_CLOSURE_PTR}}} part. 2. This is the same as my newly reported #9468 and I have no clue what that's about. Output: https://gist.github.com/nh2/0c68650b78b692e5f827 #file-error-ghc-7-6-3-linux-threaded-resurrectthreads-txt 3. This one happens very rarely; might be related to 1? Output: https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3 -linux-glibc-txt 4. The problem here is the {{{Nothing}}} case: The child process didn't answer from the pipe, and that although it is still running, so it really should have answered. It seems that for every 20th fork or so, the child process just hangs. All files, error outputs and IRC logs are also collected in this gist: https://gist.github.com/nh2/0c68650b78b692e5f827 For getting issues (1-3), you have to run them multiple times in order to reproduce; if they appear, they will appear within the first second after startup. Which of the issue appears is dependent on how many {{{_FORKS}}} you set (with a high number like the default 80, you mostly get issue 2; set down to 8 to make the other ones more probably) and with how many {{{+RTS -N}}} threads you run. 2 and 4 are definitely present in 7.8.3 as well. For 1 and 3, it would be great if you could tell me whether these are known issues and are known to be fixed in 7.8. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:50:45 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.abc4f23b7e99d43cc25b759f41225ef3@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: infoneeded 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 simonpj): I too am concerned about code complexity that does not buy performance; and also on the effect on compile time. That's not "no", just caution. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 12:58:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 12:58:57 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.c9064ee2254071653727e2cc30df5255@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: 9468 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 Aug 19 13:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:01:29 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.15f4641b6f425fa967104028f70a2d09@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: 9468 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ppud): * cc: ppud (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:01:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:01:55 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.e9e30e50bb7ae9294c69576b375f2ff8@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9468 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * related: 9468 => #9468 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:03:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:03:53 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.b2f0e603983667cca19a8d2f1806ce6a@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: simonmar AndreasVoellmy | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f9f89b7884ccc8ee5047cf4fffdf2b36df6832df/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9f89b7884ccc8ee5047cf4fffdf2b36df6832df" rts/base: Fix #9423 Summary: Fix #9423. The problem in #9423 is caused when code invoked by `hs_exit()` waits on all foreign calls to return, but some IO managers are in `safe` foreign calls and do not return. The previous design signaled to the timer manager (via its control pipe) that it should "die" and when the timer manager returned to Haskell-land, the Haskell code in timer manager then signalled to the IO manager threads that they should return from foreign calls and `die`. Unfortunately, in the shutdown sequence the timer manager is unable to return to Haskell-land fast enough and so the code that signals to the IO manager threads (via their control pipes) is never executed and the IO manager threads remain out in the foreign calls. This patch solves this problem by having the RTS signal to all the IO manager threads (via their control pipes; and in addition to signalling to the timer manager thread) that they should shutdown (in `ioManagerDie()` in `rts/Signals.c`. To do this, we arrange for each IO manager thread to register its control pipe with the RTS (in `GHC.Thread.startIOManagerThread`). In addition, `GHC.Thread.startTimerManagerThread` registers its control pipe. These are registered via C functions `setTimerManagerControlFd` (in `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The IO manager control pipe file descriptors are stored in a new field of the `Capability_ struct`. Test Plan: See the notes on #9423 to recreate the problem and to verify that it no longer occurs with the fix. Auditors: simonmar Reviewers: simonmar, edsko, ezyang, austin Reviewed By: austin Subscribers: phaskell, simonmar, ezyang, carter, relrod Differential Revision: https://phabricator.haskell.org/D129 GHC Trac Issues: #9423, #9284 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:03:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:03: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.f4b69affb83e47a09c6b835b766aa8a3@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f9f89b7884ccc8ee5047cf4fffdf2b36df6832df/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9f89b7884ccc8ee5047cf4fffdf2b36df6832df" rts/base: Fix #9423 Summary: Fix #9423. The problem in #9423 is caused when code invoked by `hs_exit()` waits on all foreign calls to return, but some IO managers are in `safe` foreign calls and do not return. The previous design signaled to the timer manager (via its control pipe) that it should "die" and when the timer manager returned to Haskell-land, the Haskell code in timer manager then signalled to the IO manager threads that they should return from foreign calls and `die`. Unfortunately, in the shutdown sequence the timer manager is unable to return to Haskell-land fast enough and so the code that signals to the IO manager threads (via their control pipes) is never executed and the IO manager threads remain out in the foreign calls. This patch solves this problem by having the RTS signal to all the IO manager threads (via their control pipes; and in addition to signalling to the timer manager thread) that they should shutdown (in `ioManagerDie()` in `rts/Signals.c`. To do this, we arrange for each IO manager thread to register its control pipe with the RTS (in `GHC.Thread.startIOManagerThread`). In addition, `GHC.Thread.startTimerManagerThread` registers its control pipe. These are registered via C functions `setTimerManagerControlFd` (in `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The IO manager control pipe file descriptors are stored in a new field of the `Capability_ struct`. Test Plan: See the notes on #9423 to recreate the problem and to verify that it no longer occurs with the fix. Auditors: simonmar Reviewers: simonmar, edsko, ezyang, austin Reviewed By: austin Subscribers: phaskell, simonmar, ezyang, carter, relrod Differential Revision: https://phabricator.haskell.org/D129 GHC Trac Issues: #9423, #9284 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:05:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:05:24 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.a37836c71d992ae13d27df0cbe97106d@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: simonmar AndreasVoellmy | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged, thanks Andreas! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:16:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:16:55 -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.99bb4e716d4779087c046089846f6c60@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T8832 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:18 hvr]: > Btw, now that I saw that commit, I've seen other testcases making use of the pre-defined `SIZEOF_HSWORD` (and there's also `WORD_SIZE_IN_BITS`) CPP symbol to test for wordsize. Would that have worked as well? Predefined by what? I tried `ghc -E -optP-dM -cpp foo.hs; cat foo.hspp` as suggested somewhere in the User's Guide to see what C preprocessor symbols were automatically defined and there wasn't anything like that among them. Or do you mean `#include`ing one of GHC's header files? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:22:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:22:59 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.62a20f16cda190fba9692a5446b308f9@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9468 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): As a side note: In unix-2.5.0.0 (GHC 7.2), the haddocks of {{{forkProcess}}} say "GHC note: forkProcess is not currently supported when using multiple processors (+RTS -N), although it is supported with -threaded as long as only one processor is being used." but as of unix-2.5.1.0 (GHC 7.4) that note is gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:29:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:29:38 -0000 Subject: [GHC] #9470: forkProcess breaks in multiple ways with GHC 7.6 In-Reply-To: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> References: <042.8781f9e320b2d4c5b0d68944c4d28b37@haskell.org> Message-ID: <057.0084acb8ac594d35890f0aae25cb42d6@haskell.org> #9470: forkProcess breaks in multiple ways with GHC 7.6 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: #9468 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): It seems that issue 4 can be worked around by restricting to 1 fork at a time (suggesed by carter): {{{#!hs main :: IO () main = do let _FORKS = 8 withLock <- do m <- newMVar () return $ \f -> withMVar m (\() -> f) forM_ [1.._FORKS :: Int] $ \i -> forkIO $ forever $ withLock $ forkJobProcess ("Job" ++ show i) _ <- getLine return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 13:42:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 13:42:34 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.f181bea334bc5ccad76be0fd072c198d@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Thanks for the report, but, ... that would be exactly the opposite of the change in commit d39c434a9518b7376857be88503055ecb7d0fe1f "Make configure's sed(1) expression for GHC_LDFLAGS more BSD-friendly.", so I guess we will need some kind of autodetection or other way to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 14:46:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 14:46:20 -0000 Subject: [GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c) In-Reply-To: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> References: <052.9c2a439965f718a8964f4e460ff5ae13@haskell.org> Message-ID: <067.91612a8db0047505e62bc4c136b9e0e6@haskell.org> #9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 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 thoughtpolice): * version: 7.8.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 16:43:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 16:43:00 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.54bfd1214272569575ff0d55a94bf599@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): A discussion with various Experts revealed the following story: GHC has a `PolyTv` flavor of meta-variable that, according to its description, is meant to unify with sigma-types. But, the original intent was more than that: it should unify with anything, always. We sometimes want `tcExpr` to ''check'' a type, and we sometimes want it to ''infer'' a type. We can imagine two functions like this: (indeed, we ''have'' two functions like this!) {{{ tcInfExpr :: HsExpr Name -> TcM (HsExpr TcId, TcType) tcExpr :: HsExpr Name -> TcType -> TcM (HsExpr TcId) }}} If both of these were fully implemented, they would each have many similar cases and would be more work to maintain. This is why `tcInfExpr` currently has just a few cases and then delegates to `tcExpr`, passing in a unification variable. The problem is that the unification variable, currently a `TauTv`, won't unify with all types. What we want, in effect, is this: {{{ data TcDirection = Infer (Ref TcType) | Check TcType tcExpr :: TcDirection -> HsExpr Name -> TcM (HsExpr TcId) }}} But, if we had a unification variable that unifies with ''anything'', then we have exactly that: the permissive unification variable is essentially a `Ref TcType`! We can use a `PolyTv` as this permissive unification variable. The ''only'' place where `PolyTv` is currently used is in the special typing rule for `($)` (and its presence there is suspect -- see below). So, all we have to do is update `checkTauTvUpdate` to not check `PolyTv`s at all, and we get this behavior for `PolyTv`. So, the current proposed solution is to get rid of `TcInfExpr` (as already done in my branch) and instead use a `PolyTv` in `tcInfer`, along with liberalizing the meaning of `PolyTv`. To make sure we've done this right, we should also verify that `PolyTv`s are indeed filled in right away, before the constraint solver. In particular: * Zonking (even the partial zonking done by `zonkTcType` and friends) should ''never'' encounter a `Flexi` `PolyTv`. (Nagging worry about the possibility of underspecified types here.... may need defaulting.) * The constraint solver should ''never'' encounter a `PolyTv`. About `($)`: There is a curious piece of code here: {{{ tcExpr (OpApp arg1 op fix arg2) res_ty | (L loc (HsVar op_name)) <- op , op_name `hasKey` dollarIdKey -- Note [Typing rule for ($)] = do { traceTc "Application rule" (ppr op) ; (arg1', arg1_ty) <- tcInferRho arg1 ; let doc = ptext (sLit "The first argument of ($) takes") ; (co_arg1, [arg2_ty], op_res_ty) <- matchExpectedFunTys doc 1 arg1_ty ; a_ty <- newPolyFlexiTyVarTy ; arg2' <- tcArg op (arg2, arg2_ty, 2) ; co_a <- unifyType arg2_ty a_ty -- arg2 ~ a ; co_b <- unifyType op_res_ty res_ty -- op_res ~ res ; op_id <- tcLookupId op_name ; let op' = L loc (HsWrap (mkWpTyApps [a_ty, res_ty]) (HsVar op_id)) ; return $ OpApp (mkLHsWrapCo (mkTcFunCo Nominal co_a co_b) $ mkLHsWrapCo co_arg1 arg1') op' fix (mkLHsWrapCo co_a arg2') } }}} My question is: why have `a_ty` at all? The type of the left-hand argument to `($)` is properly captured in `arg_ty`, and I can't see a reason to then unify with the fresh `a_ty`. Does anyone have insight here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 16:51:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 16:51:44 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.86265da1497685534748305b7a180c7c@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 simonpj): Re the last question, here's the comment in HEAD {{{ -- Make sure that the argument type has kind '*' -- Eg we do not want to allow (D# $ 4.0#) Trac #5570 -- (which gives a seg fault) -- We do this by unifying with a MetaTv; but of course -- it must allow foralls in the type it unifies with (hence PolyTv)! -- -- The result type can have any kind (Trac #8739), -- so we can just use res_ty -- ($) :: forall (a:*) (b:Open). (a->b) -> a -> b ; a_ty <- newPolyFlexibTyVarTy }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 17:59:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 17:59:32 -0000 Subject: [GHC] #9404: tcInferRho muddies the waters In-Reply-To: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> References: <047.891f32808c0ce61dfe70309b4843a6ab@haskell.org> Message-ID: <062.272fab1525dda682125e0d08028f7ef0@haskell.org> #9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): Of course. How silly of me -- I saw that comment but somehow didn't realize it answered my question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 18:24:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 18:24:00 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.cca874d9560309df315fe5d75f44b919@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Hi, sorry for getting to this rather later, but as Solaris user I'm curious how the patches will affect common Solaris 11/10. For example on Solaris 11.1 which I'm using now, I don't see this issue with GHC 7.6.3: {{{ $ /opt/ghc-7.6.3/bin/ghci -threaded GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Warning: -debug, -threaded and -ticky are ignored by GHCi Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) /lib/librt.so ... done final link ... done Prelude> }}} it looks like dyson here diverges from common Solaris probably since if I for example check libdl, then I see it defined and containing functions: {{{ $ nm /lib/libdl.so.1 /lib/libdl.so.1: [Index] Value Size Type Bind Other Shndx Name [4] | 476| 0|SECT |LOCL |0 |3 | [9] | 0| 0|SECT |LOCL |0 |8 | [10] | 0| 0|SECT |LOCL |0 |9 | [11] | 0| 0|SECT |LOCL |0 |10 | [2] | 116| 0|SECT |LOCL |0 |1 | [3] | 340| 0|SECT |LOCL |0 |2 | [7] | 2088| 0|SECT |LOCL |0 |6 | [5] | 768| 0|SECT |LOCL |0 |4 | [6] | 1312| 0|SECT |LOCL |0 |5 | [8] | 2388| 0|SECT |LOCL |0 |7 | [31] | 0| 0|FUNC |GLOB |0 |ABS |_dladdr [35] | 0| 0|FUNC |GLOB |0 |ABS |_dladdr1 [37] | 0| 0|FUNC |GLOB |0 |ABS |_dlclose [19] | 0| 0|FUNC |GLOB |0 |ABS |_dldump [15] | 0| 0|FUNC |GLOB |0 |ABS |_dlerror [20] | 0| 0|FUNC |GLOB |0 |ABS |_dlinfo [18] | 0| 0|FUNC |GLOB |0 |ABS |_dlmopen [38] | 0| 0|FUNC |GLOB |0 |ABS |_dlopen [44] | 0| 0|FUNC |GLOB |0 |ABS |_dlsym [17] | 116| 0|OBJT |GLOB |0 |1 |_DYNAMIC [36] | 0| 0|OBJT |GLOB |0 |ABS |_edata [41] | 4096| 0|OBJT |GLOB |0 |7 |_end [12] | 4096| 0|OBJT |LOCL |2 |7 |_END_ [39] | 2456| 0|OBJT |GLOB |0 |7 |_etext [40] | 0| 0|FUNC |GLOB |0 |ABS |_ld_libc [46] | 0| 0|OBJT |GLOB |0 |ABS |_PROCEDURE_LINKAGE_TABLE_ [13] | 0| 0|OBJT |LOCL |2 |1 |_START_ [43] | 0| 0|FUNC |GLOB |0 |ABS |dl_iterate_phdr [42] | 0| 0|FUNC |GLOB |0 |ABS |dladdr [45] | 0| 0|FUNC |GLOB |0 |ABS |dladdr1 [33] | 0| 0|FUNC |GLOB |0 |ABS |dlclose [28] | 0| 0|FUNC |GLOB |0 |ABS |dldump [22] | 0| 0|FUNC |GLOB |0 |ABS |dlerror [32] | 0| 0|FUNC |GLOB |0 |ABS |dlinfo [25] | 0| 0|FUNC |GLOB |0 |ABS |dlmopen [14] | 0| 0|FUNC |GLOB |0 |ABS |dlopen [16] | 0| 0|FUNC |GLOB |0 |ABS |dlsym [1] | 0| 0|FILE |LOCL |0 |ABS |libdl.so.1 [27] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_0.7 [29] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_0.8 [21] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_1.1 [23] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_1.2 [24] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_1.3 [26] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_1.4 [30] | 0| 0|OBJT |GLOB |0 |ABS |SUNW_1.5 [34] | 0| 0|OBJT |GLOB |0 |ABS |SUNWprivate_1.1 }}} I understand the offered logic behind the change from AC_CHECK_LIB to AC_SEARCH_LIB, but I'm not sure if this is the best approach. Honestly I'm not sure if what Dyson does here is the correct thing or not. I'll try to merge your patches here and test on real Solaris 11 and see if breaks anything or not. Still if you are Dyson developer I would appreciate some in-depth info why you use libs this way, i.e. why you attempt to define libdl/librt as linker scripts instead of simply omitting them... Thanks Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 18:27:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 18:27:40 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.9d6b885a483f68600d0e3dec1509e2ce@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I think that an answer could be to use -E instead of -r (http://www.freebsd.org/cgi/man.cgi?query=sed) although this will presumably not be compatible with gnu sed. Did the repvious version not work at all with BSD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 18:38:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 18:38:30 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.582de5c96d6e45f6a79ea1eb2b0496cf@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): Hi, this changes won't affect solaris. The patch make GHC only check whether we need libdl or libpthread. If not it will not load them. On Solaris libdl is a filter library. It exists only for backward compatibility. dlopen() function really is not even in libc, but in runtime linker ld.so. As for Dyson hack: I use GNU binutils. I had linker (GNU ld) problems when linking filter libraries, e. g. symbols versions mismach or so, can't remember. In come cases I was not able to link libpthread.so or librt.so. But on Solaris, illumos and Dyson I don't need to, because all functions are in libc (ld.so) Unfortunately, many (== almost all ;-) packages does not check whether they need these libraries, some of packages link them unconditionally, e. g. gcc -ldl -lpthread, etc. So instead of using real symlinks like libdl.so -> libdl.so.1, I made libdl.so be a file with [GNU] linker script with does nothing. Thus every package is happy finding these libs, and I don't have linking errors. In the ideal world GHC should load real library, not a developer symlink, e. i. libdl.so.1 instead of just libdl.so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 18:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 18:42:13 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.22edd39fe7b9f0da6c6ca59446a6081f@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): You can see here https://github.com/illumos/illumos- gate/tree/master/usr/src/cmd/sgs/libdl that there is no code in libdl. Instead it is filter library https://github.com/illumos/illumos- gate/blob/master/usr/src/cmd/sgs/libdl/amd64/Makefile -F flag is supported even by GNU ld. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 18:46:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 18:46:21 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.81849a2fe4f84013e1fd1c2bf8d82753@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): Also, having e. g. libdl.so -> libc.so is not an options either. In this case libc can be linked in before libgcc_s, and executable will use wrong unwind function *BANG!* :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 22:42:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 22:42:17 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.61fd425c834352b4b2bb3862cb3b88bf@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by pgj): * owner: => pgj Comment: I made the commit, assign to self. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 22:44:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 22:44:35 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.27f4a39e27546a3d5ee6fe09f963d949@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:3 jrp]: > I think that an answer could be to use -E instead of -r (http://www.freebsd.org/cgi/man.cgi?query=sed) although this will presumably not be compatible with gnu sed. For what it is worth, to my findings, GNU sed actually supports the {{{-E}}} flag, but it is not documented on its manual page. > Did the repvious version not work at all with BSD? No, it did not work with FreeBSD. We had a solution in the Ports Collection for that, so I naively thought that it could be just put upstream, but apparently I was (quite) wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 19 23:16:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Aug 2014 23:16:10 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.f322dec1dec7b2710aeee242a11d96c2@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): All right, I have rewritten the whole expression with perl. (Perl should be present at build time as it is required for booting.) Could you please the attached patch? Note that you shall run the {{{autoreconf}}} command in order have your {{{configure}}} script updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 00:20:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 00:20:29 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.54313cafe82385e7068c0def09522ae1@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Thanks. perl / awk were going to be my next suggestion! (Exercise for the reader: do it in bash scipt :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 01:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 01:14:54 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.904e1171e78f6f80a6edd09beea1c7db@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by pumpkin): * cc: pumpkingod@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 01:37:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 01:37:40 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.66836120a1ef74aaacb94f38477da3a8@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by rodlogic): I would just like to document another potential use case for this in addition to the Cloud Haskell one: [http://haste-lang.org/haskell14.pdf A Seamless, Client-Centric Programming Model for Type Safe Web Applications]. I am thin on the details here since I just came across the paper, but the idea is to provide an: ... alternative programming model based on Haskell, in which web applications are written as a single program rather than as two independent parts that just so happen to talk to each other. And: The remote function takes an arbitrary function, provided that all its arguments as well as its return value are serializable through the Serialize type class, and '''produces a typed identifier which may be used to refer to the remote function'''. In this example, the type of greetings is Remote (String ? Server ()), indicating that the identifier refers to a remote function with a single String argument and no return value. Remote functions all live in the Server monad. The part of the program contained within the App monad is executed on both the server and the client, albeit with slightly different side effects, as described in section 3. And here is a simple example: {{{#!haskell import Haste.App helloServer :: String ? Server () helloServer name = liftIO $ putStrLn (name ++ " says hello!") main :: App Done main = do greetings ? remote helloServer runClient $ do name ? prompt "Hi there, what is your name?" onServer (greetings <.> name) }}} I know this is not the core of the design space, but it is another dimension to consider. For example, being able to customize the closure serialization format could be an important requirement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 01:47:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 01:47:36 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.c96eaf5ab998ae8fc6f10cbb4b8a4105@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): I merged my work with a recent master. See the `wip/llf` branch and the (growing) notes at LateLamLift. Please email me with any questions you have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 04:02:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 04:02:53 -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.8abab184a9a945e66bdc8731f12f6efe@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): 9c2904c, the tip of `wip/llf`, using my recommended settings (cf LateLamLift) does lift our `$wa4` (or whatever lead to it). The new attachment is the output of `/home/nifr/tmp/llf-for-9279/bin/ghc -fforce-recomp -O2 $(echo $(cat ~/ghc-llf/llf-nr10-r6)) -c Haxl/Core/Monad.hs -ddump-llf -ddump-simpl -dsuppress-all`. The subcommand spews out the "recommended settings" that I refer to as llf-nr10-r6. HTH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 04:20:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 04:20:47 -0000 Subject: [GHC] #9471: Slimming For You Message-ID: <049.d37685c94953ba76074166c32b1daa5d@haskell.org> #9471: Slimming For You -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- Everyone today likes to ikon as depict perfect. State over-weight has prettify a starring job for everyone. Grouping suffering from unreasonable metric encounter problems mentally as source as physically. This can country the line of blood leading to heart problems that [http://ketoneslimxtadvice.com/ Ketone Slim XT]is invigoration threatening. State turn and fit not exclusive improve you physically but mentally too. It sure boosts your authority direct and personality. Slimming yourself has perks, you can bear al the clothes you've ever hot to. A fit personality testament support you excrete your own operator.Taking needy fasting or fasting pills and abstinence for several days may work you in losing coefficient. But it leave flush create you to impairment your eudaemonia that mightiness permit your hunch. It may also throttle your else meat. You must analyze retarded ways to get your coefficient death. One is to see out your daily kilocalorie intake. The soul way for coefficient casualty is to color the unneeded and non- necessary calories. move with your regular fasting. Eating fewer doesn't tight you forbid winning food. You can mortal your food that is counterbalanced and nutritious. Y http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 05:15:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 05:15:39 -0000 Subject: [GHC] #9472: Beat Your Thirst And Top-up Your Health Along With Message-ID: <049.d4e6265f952e5b16ccc753a2d4d4669f@haskell.org> #9472: Beat Your Thirst And Top-up Your Health Along With -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- Having a maturation condition with its wherewithal to bracing flushed for more than threesome life, various health biology slimming technicians have determined that it is virtually unimaginable to distribute a nutritional goodness associated with acai berries aroun[http://ketoneslimxtadvice.com/ Ketone Slim XT] d the sphere with no losing what issues most, its prosperity evaluate. This is one of the reasons why the acai berry can be purchased in a action of forms. It is unremarkably purchased in solid conduct to be put into your favorite dishes, or maybe it can be ingested for a concentrate as a nutritional attach. One word whilst that a great umteen wellbeing supporters fuck institute to be exhilarating and commencement with, the acai berry biology slimming fluffy gel, since it's traducement suggests, is definitely a tiny sorted fresh production that is tightly filled with umpteen dissimilar types of nutrients, mineral deposits, minerals, oily as healthy as paraffin acids, and various others that greatly results in our body's well-being. The acai berry are exclusive allowed to be placed in the The river online marketplace earth. In fact a lot statesman than 90% of Acai Berry creation are sourced via Southeasterly the USA. And additionally owing to that, its virtually out of the subject to browse for them reinvigorated. http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 06:04:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 06:04:58 -0000 Subject: [GHC] #9473: Health Benefits Of Having Super Slimming Tea Message-ID: <049.6b411111d7a076812552cab06dce79f5@haskell.org> #9473: Health Benefits Of Having Super Slimming Tea -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- n this ultramodern era, fill use foods suchlike vivace content or junk foods which take much tasteful, fat, sweetening etc. this of matter and sedentary style, dynamic name of facility, hi-tech fashion is the w[http://ketoneslimxtadvice.com/ Ketone Slim XT] ater understanding for blubber. And also this information is progressive quick for the lastly few decades all over the humankind. This is the important venture of diabetes, organs diseases and stroking. There are numerous preventative measures and one of it is boozing naive tea regular.According to researchers latterly it has been recovered that drinking site tea two to trio times regular can get benevolent personalty on murder sweeten collection. Researches also say that depletion of veggie tea can alter inferior amount of diabetes. We can see this apparently in the rum[http://ketoneslimxtadvice.com/ Ketone Slim XT] inate of MEDIS Epidemiology. In that learn, it is shown that in natives of Mediterranean island who use tea for longstanding punctuation aids to minify the occurrence of diabetes mellitus. Drinking of statesman than seventy rotund women who drinking viridity tea daily leash nowadays person reduced their fat to some probative take within xii weeks.Imbibing viridity tea also has different benefits. Gore vessels get distended finished the ingestion. It is apparently proven in Greece essay results the describe shows that arterial vessels expansion has been accrued to almost ternary and a half proportionality. From cohort contemplation of Island, we can see that consumption of naif tea regular helps to bound the cog http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 06:37:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 06:37:56 -0000 Subject: =?utf-8?q?=5BGHC=5D_=239474=3A_Safe_Slimming_Pills_=26_Appetite_?= =?utf-8?b?U3VwcHJlc3NhbnQgUmV2aWV3cyDvv73vv70gSW50?= Message-ID: <049.b6a8d9b48ca5270d39a71058c7aa86de@haskell.org> #9474: Safe Slimming Pills & Appetite Suppressant Reviews ?? Int -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- Unbleached slimming pills are perhaps the champion way to enjoy weight direction or fat loss without having to egest do with sulphurous routines or take program. Nonetheless, how much of these uninjured slimming pills can actually be titled unhurt is lawless to moot. Spell whatever firms do concern the strictest of scanning and filt[http://ketoneslimxtadvice.com/ Ketone Slim XT] ering measures to ensure that the spontaneous weight casualty pills are the good and the safest in the marketplace, whatsoever don't. This becomes pretty marmoreal to distinguish and key when it comes perfect to hundreds of online pills that assign fast earthy one command coefficient finished much unaffected slimming pills and yet cook your welfare in insure? Good, there are whatsoever painless distance out on this one, but the easiest choice is to fix be[http://ketoneslimxtadvice.com/ Ketone Slim XT] lt of the faction appetite drug reviews online and pass towards purchasing what they advocate. This does not, however, meanspirited that these appetency suppressant reviews are the say-all of the consumer get decisions. Time a lot of these reviews can be germinal, both of them are also remunerative for by organized firms and manufacturers to fast-forward their marketing drive sales outcomes. So if you are effort to bearing in screen and look not to be conned, you faculty be immoral. Let's focu http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:11:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:11:59 -0000 Subject: [GHC] #9475: easy Slimming Diet To Control Overweight Message-ID: <049.297c11ccf4132b09d775f50f289127c0@haskell.org> #9475: easy Slimming Diet To Control Overweight -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- recipes from your experts, friends or Cyberspace. Here, experts from lida daidaihua share a perfect two day slimming diet. [http://ketoneslimxtadvice.com/ Ketone Slim XT] Before we go to the point of slimming 2 day fasting recipe, we should pretend it withdraw why such diet is white for losing weight or controlling rapid development of body coefficient. Nutrients suchlike potassium, metal, catalyst, and trait are determining to fending off or fighting sharp execution somatesthesia. You do not person to pass apiece one, though. Rightful accentuate the foods you screw ever been told to eat (fruits, veggies, intact grains, insufficient catalyst, and low-fat dairy),[http://ketoneslimxtadvice.com/ Ketone Slim XT] while dodging those we have grown to screw (calorie- and fat-laden sweets and red meat). Top it all off by stem endorse on flavoring, and viola!So, we hit taken the module of action 2 day diet nihon lingzhi as an alternative to exit weight. In the followers parts, we go to the part recipe you essential.No matter group is off-limits"you testament get your apportion of incline meat, gallinacean, and seek; object grains; fruits and vegetables; farm; legumes, nuts, and seeds; a younger fat; and a few sweets. Foods gilded in potassium, calcium, catalyst, a http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:19:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:19:36 -0000 Subject: [GHC] #9476: Implement late lambda-lifting Message-ID: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:19:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:19:47 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.927b63c5ba28723d2064acbf63a3cd3f@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => nfrisby -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:20:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:20:50 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.9aae7166fef9ec21d93b6c764d5f2491@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): Excellent work, thank you. This ticket is about SAT, so I've started a new ticket, #9476, to track progress on late lambda lifting. Let's move further discussion about LLF to there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:25:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:25:15 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.94069a9786716a74b3c7047ee8631b95@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby 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): Thoughts about the wiki page (which is a fantastic start): * The "extended consequences" section is great. But could you give a small example of each point? Otherwise it is hard to grok. There are lots of other places where an example would be extremely useful. To take just one "If an LNE function f occurs in another LNE function g and we only lift g, then it will spoil f: and it will no longer be an LNE, because it will now be an argument to llf_g." * I recall that you implemented a more-or-less complex analysis to try to get the good consequences without the bad ones. Is it worth sketching what the analysis does? The complexity here is my principal worry about the whole thing. * Small point: the `$(theRHS 'a 'b)` notation is more distracting than helpful. I'd use something more informal `(..a...b...)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:47:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:47:29 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.c1b9ba0a2da869baa956bb200045b3d7@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > .. as described in "Towards Haskell in the Cloud". New description: .. as described in "Towards Haskell in the Cloud". See also #9429, which is closely related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:47:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:47:52 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.e60f8d559d0ba2d44ebecf1a8f4194c0@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > .. as described in "Towards Haskell in the Cloud". > > See also #9429, which is closely related. New description: .. as described in "Towards Haskell in the Cloud". See also #9429 (Alternative to type family `Any`), which is closely related. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:49:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:49:35 -0000 Subject: [GHC] #9477: 10 Self-care Secrets For Slimming Down Message-ID: <049.66bcfd1a536ff0182e2b425f6ac87e7a@haskell.org> #9477: 10 Self-care Secrets For Slimming Down -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- When experts reprimand us on coefficient departure, it is commonly all some utilize, calories and carbs. That is groovy accumulation, but from one driven feeder to another, I bang provided any otherwise tips that do not ordinarily make the diet books. They faculty compel several try, but I fuck open them to be intrinsic to seemly self-care and unit deprivation. [http://ketoneslimxtadvice.com/ Ketone Slim XT] 1. Quietus: It is so smooth to overeat when we are jaded. We reaching for nutrient to donjon us leaving, thought we give hit much doe the solon we eat. Retributive the opposite happens. When we overeat we comprehend bad, ponderous, and dazed. And we are soothe weary! Employ on going to bed earlier. Belatedly nighttime nibbling is easier when it is dead and we should be in bed. Stomach transport the lights out before your breadbasket starts to emit. Flat if it is growling, go to bed, you will not center it when you are hypnoid and it feels sooo serious to raise up in the morning with a exonerated conscience! [http://ketoneslimxtadvice.com/ Ketone Slim XT] 2. Vitamins: So umteen nowadays our overeating is caused by nutritional deficiencies. We assay the vitamins and minerals our bodies want in immoderateness substance. Unluckily, this is a vicious oscillation because commonly the food we overeat is devoid of any historical nutrition, so it leaves us encourage low. As a premiere move, act winning a groovy multivitamin, preferably one prefabricated from intact substance. (If you go to a upbeat substance store, they faculty supply healthy substance supplements, not fitting synthetic ones.) Succeeding, labor to eat feed foods whose earth is not minimal of vital minerals http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:52:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:52:25 -0000 Subject: [GHC] #9478: Partial type signatures Message-ID: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> #9478: Partial type signatures -------------------------------------+------------------------------------- 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: Phab:D168 -------------------------------------+------------------------------------- This ticket tracks progress on '''partial type signatures'''. * Wiki page [wiki:PartialTypeSignatures] * Phabricator link: Phab:D168 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:53:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:53:21 -0000 Subject: [GHC] #9478: Partial type signatures In-Reply-To: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> References: <046.53a47ac5f73cf1b7df317af2585f061e@haskell.org> Message-ID: <061.539369be294fe3eb2d0374f07391913c@haskell.org> #9478: Partial type signatures -------------------------------------+------------------------------------- Reporter: simonpj | 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: Phab:D168 | -------------------------------------+------------------------------------- Changes (by simonpj): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:57:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:57:58 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole Message-ID: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ?_h? with type: a0 Where: ?a0? is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ?show?, namely ?_h? In the expression: show _h In an equation for ?test?: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ?_h? with type: a0 Where: ?a0? is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ?show?, namely ?_h? In the expression: show _h In an equation for ?test?: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 07:58:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 07:58:23 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.8c03410ed1e5f537c932f2e6112ba8e1@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: low | Keywords: holes 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 dominiquedevriese): Note: this report was triggered by the following StackOverflow question: http://stackoverflow.com/questions/23028124/is-there-a-way-to-make-ghc- provide-the-type-class-constraints-of-typed-holes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 08:12:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 08:12:54 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly Message-ID: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A segfault occurs when using the GHC API with Shelly. I do not know why. Here is a code snippet that triggers it: {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags $ dflags { hscTarget = HscInterpreted, ghcLink = LinkInMemory } imports <- mapM parseImportDecl ["import Shelly", "import Prelude"] setContext $ map IIDecl imports runStmt "shelly undefined" RunToCompletion }}} Note that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following: {{{ Linux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux }}} I cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 08:13:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 08:13:27 -0000 Subject: [GHC] #9140: Unboxed tuples fails in GHCi (7.8.2) In-Reply-To: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> References: <043.e772ef621570bdd1125a1843a3859a14@haskell.org> Message-ID: <058.8130cbe8acbe801eea2aca2035ae5b4e@haskell.org> #9140: Unboxed tuples fails in GHCi (7.8.2) -------------------------------------+------------------------------------- Reporter: osa1 | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: tests/ghci/scripts/T9140 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"27c99a1f8399fd6cb8931c17385102747556b6cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="27c99a1f8399fd6cb8931c17385102747556b6cc" Comments fix to Trac #9140 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 08:52:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 08:52:21 -0000 Subject: [GHC] #9481: You Can Succeed At Weight Loss Message-ID: <049.78d63af565e2a476cda178770ef2bad2@haskell.org> #9481: You Can Succeed At Weight Loss -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- Forward things position, retributive most all mortals bonk had to confronting a metric job at any period in their world; for a lot of ladies it power be after the exploit of their kids... males oftentimes change an acceleratory region merchandise erstwhile they see them[http://ketoneslimxtadvice.com/ Ketone Slim XT]selves impermanent a lot of dimension at their pass instead of at the gymnasium.The Upbeat Study that was through for England forecasts that over dozen meg grownups and a million kids could be fat by 2010 if no spread is adoptive.Forceful travail is all important to coefficient going and those that feature adopted exertion in an endeavour to assemblage off a couple of pounds module still you that the profits far outbalance exclusive the decline of energetic scheme fat.To slim thrown quick and efficaciously, cardinal aspects of aliveness had outperform be castrated: what to eat on, how to take, deportment as fountainhead as corporal activeness nutrition, suchlike a portion of whole-grain toasted money, is a premium prize. [http://ketoneslimxtadvice.com/ Ketone Slim XT] Do not abandon carbs except you actually requisite to, since habitually individuals support thick carb substantiate downs and decorativeness up http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 09:05:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 09:05:01 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.3f24c823402006e0c0b634d6e10f7508@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: low | Keywords: holes 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 mentheta): How can I watch this ticket for activity? I am interested in future development related to this feature. I'm sorry if this "meta question" is out of place, but I couldn't find a "watch button" either on this page, or for trac in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 09:23:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 09:23:07 -0000 Subject: [GHC] #9482: Safe Weight Loss: The Guaranteed Way To A Message-ID: <049.f3c0244cca1aa71394b67bb7f4ebd5ac@haskell.org> #9482: Safe Weight Loss: The Guaranteed Way To A -------------------------------------+------------------------------------- Reporter: teddybobie | 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: -------------------------------------+------------------------------------- Did you know that yo-yo dieting (losing, then gaining, then losing weight and so on) is incredibly bad for your wellbeing? Your body honorable doesn"t see what"s exploit on. Oldest it has lack, then banquet, then la[http://ketoneslimxtadvice.com/ Ketone Slim XT] ck again . . . and what"s much, this action gift drive your metastasis to slack fallen and request onto fat because your body thinks there strength be added lack on the way. So you"ll oft end up weighing much than you did in the freshman point. I can"t enounce sufficiency the importance of safe metric diminution -- for both your eudaimonia and your personage. [http://ketoneslimxtadvice.com/ Ketone Slim XT] The key to invulnerable unit amount is to support your measure. Yes, I cognize, you require to get small equivalent yesterday. But if you consider nearly it, wouldn"t you kinda be thin for being than go on many irrupt fast, retrogress a lot of unit and put it all substantiate on again? If you essential to be thin for bully, you"ll someone to advantage thinking equal a turn organism, so that bit by bit the pounds bead off -- and this prime situation to looking at is your desire versus your perceived desire. Rightful thirst is a really special notion which you may hold irrecoverable how to retrieve; if you"re a habitual over-eater you probably never let yourself get the component of hunger so you don"t e'er comprehend it anymore. In that human, it can be valuable to go without substance for half a day, http://ketoneslimxtadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 10:25:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 10:25:44 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects Message-ID: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | 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: -------------------------------------+------------------------------------- '''Summary''': Given two object files (created from C files) A and B, where B refers to symbols defined in A, if we load B before A, calling `resolveObjs` after each object file, symbol resolution goes wrong. Full test case attached. '''Detailed description''': Consider {{{#!c // a.c #include void defined_in_A() { printf("In A\n"); } }}} {{{#!c // b.c #include void defined_in_A(); void defined_in_B() { printf("In B\n"); defined_in_A(); printf("In B\n"); } }}} and {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import System.IO foreign import ccall "defined_in_B" defined_in_B :: IO () main :: IO () main = defined_in_B }}} and we use the GHC API to load the object files `a.o` and `b.o` (corresponding to `a.c` and `b.c`), calling `resolveObjs` after loading each object, and then load `Main` and call `Main.main`, everything works fine (the attached test case contains both `a.c`, `b.c` and `Main.hs` as well as the test program that calls into the GHC API). However, if we load `b.o` ''before'' `a.o`, things go wrong. When we load `b.o` and call `resolveObjs` then `resolveObjs` (quite reasonably) complains that {{{ lookupSymbol failed in relocateSection (relocate external) b.o: unknown symbol `_defined_in_A' }}} since we haven't loaded `a.o` yet. But when we then load `a.o` and call `resolveObjs` again, `resolveObjs` reports okay, but something goes wrong because the program subsequently segfaults. '''A successful run''' I took a closer look at what happens exactly. First, let's consider the test run where we load A before B, and everything works fine, and let's look at the precise code that we actually execute when `Main.main` does the foreign call to `defined_in_B`: {{{ # lldb Linkerbug Current executable set to 'Linkerbug' (x86_64). (lldb) breakpoint set -n ffi_call Breakpoint 1: where = Linkerbug`ffi_call + 29 at ffi64.c:421, address = 0x0000000102be2eed (lldb) run Process 92361 launched: 'Linkerbug' (x86_64) Loading object "a.o" symbol resolution ok Loading object "b.o" symbol resolution ok Loading Haskell module "Main.hs" ok Running "Main.main" Process 92361 stopped * thread #1: tid = 0x32048b, 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421 (lldb) disassemble -c 14 -s fn 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: pushq %rbx 0x104c6c215: pushq %rax 0x104c6c216: leaq 0x1d(%rip), %rbx 0x104c6c21d: movq %rbx, %rdi 0x104c6c220: callq 0x104c6c3c8 0x104c6c225: xorl %eax, %eax 0x104c6c227: callq 0x104c6b210 0x104c6c22c: movq %rbx, %rdi 0x104c6c22f: addq $0x8, %rsp 0x104c6c233: popq %rbx 0x104c6c234: popq %rbp 0x104c6c235: jmpq 0x104c6c3c8 }}} This disassembly is the compiled code for B which, in order, does a call to `printf`, then to `defined_in_A`, and then back to `printf` (the last call is `jmpq` rather than `callq`: the C compiler did a tail call optimization). Let's make sure that this is actually true; the first call is a call to {{{ (lldb) disassemble -c 2 -s 0x104c6c3c8 0x104c6c3c8: jmpq *-0xe(%rip) 0x104c6c3ce: addb %al, (%rax) }}} which is an indirect jump to {{{ (lldb) memory read -f A -c 1 "0x104c6c3ce - 0xe" 0x104c6c3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} to `puts`, okay, good. Seems an unnecessary level of indirection, but that's okay. The next call is to {{{ (lldb) disassemble -c 5 -s 0x104c6b210 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: leaq 0x6(%rip), %rdi 0x104c6b21b: popq %rbp 0x104c6b21c: jmpq 0x104c6b370 }}} which is the compiled code for `defined_in_A`, which should be just a call to `printf`. Let's confirm: {{{ (lldb) disassemble -c 2 -s 0x104c6b370 0x104c6b370: jmpq *-0xe(%rip) 0x104c6b376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b376 - 0xe" 0x104c6b368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} Ok, all good. '''A failed run''' Now let's check what happens when we load the objects in the opposite order. The code that we execute is {{{ (lldb) disassemble -c 14 -s fn 0x104c6b210: pushq %rbp 0x104c6b211: movq %rsp, %rbp 0x104c6b214: pushq %rbx 0x104c6b215: pushq %rax 0x104c6b216: leaq 0x1d(%rip), %rbx 0x104c6b21d: movq %rbx, %rdi 0x104c6b220: callq 0x104c6b3c8 0x104c6b225: xorl %eax, %eax 0x104c6b227: callq 0x104c6c210 0x104c6b22c: movq %rbx, %rdi 0x104c6b22f: addq $0x8, %rsp 0x104c6b233: popq %rbx 0x104c6b234: popq %rbp 0x104c6b235: jmpq 0x104c6b556 }}} This immediately looks suspicious: the address of the `jmpq` (the second -- tail -- call to `printf`) is different from the first. The first `callq` is okay: {{{ (lldb) disassemble -c 2 -s 0x104c6b3c8 0x104c6b3c8: jmpq *-0xe(%rip) 0x104c6b3ce: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6b3ce - 0xe" 0x104c6b3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} and the call to `defined_in_A`, as well as the code ''for'' `defined_in_A`, are both ok: {{{ (lldb) disassemble -c 5 -s 0x104c6c210 0x104c6c210: pushq %rbp 0x104c6c211: movq %rsp, %rbp 0x104c6c214: leaq 0x6(%rip), %rdi 0x104c6c21b: popq %rbp 0x104c6c21c: jmpq 0x104c6c370 (lldb) disassemble -c 2 -s 0x104c6c370 0x104c6c370: jmpq *-0xe(%rip) 0x104c6c376: addb %al, (%rax) (lldb) memory read -f A -c 1 "0x104c6c376 - 0xe" 0x104c6c368: 0x00007fff84fd5b9b libsystem_c.dylib`puts }}} However, that second call to `printf` (the `jmpq`) in `defined_in_B` is indeed wrong: it's jumping into nowhere: {{{ (lldb) memory read -c 8 0x104c6b556 0x104c6b556: 00 00 00 00 00 00 00 00 ........ }}} Note that somewhat surprisingly is it ''not'' the resolution of the symbol from `a.o` that is wrong; that ''does'' get resolved okay once we load `a.o`; rather, it is the jump to `puts` which is wrong (and then only the one of them). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 11:47:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 11:47:34 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.a59dd9d0a6db3d38db12095c4de08ec6@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: low | Keywords: holes 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): Open up the "Modify Ticket" option near the comment box and add your email to the "Cc" field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 12:38:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 12:38:12 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.eb77114d09689c742788cf7caf320445@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase 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 rodlogic): Should this be closed or is a test case still pending? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 13:03:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 13:03:49 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects In-Reply-To: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> References: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> Message-ID: <059.6d863e6d56fcf71366652ee4cb22d38e@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I should be able to reproduce by downloading all the attachments and running `make` followed by `Linkerbug` right? In that case it seems to work for me (GHC 7.8.3, Linux x86_64): {{{ rwbarton at morphism:/tmp/linkerbug$ make ghc -c -O a.c ghc -c -O b.c ghc -package ghc Linkerbug [1 of 1] Compiling Main ( Linkerbug.hs, Linkerbug.o ) Linking Linkerbug ... rwbarton at morphism:/tmp/linkerbug$ ./Linkerbug Loading object "b.o" Linkerbug: b.o: unknown symbol `defined_in_A' symbol resolution failed Loading object "a.o" symbol resolution ok Loading Haskell module "Main.hs" ok Running "Main.main" In B In A In B ok }}} I assume you are on OS X? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 13:10:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 13:10:44 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects In-Reply-To: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> References: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> Message-ID: <059.e288014973cb788b647822b9ea7d216f@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by edsko): Yup, I'm on OSX. For me this gives: {{{ # make ghc -c -O a.c ghc -c -O b.c ghc -package ghc Linkerbug [1 of 1] Compiling Main ( Linkerbug.hs, Linkerbug.o ) Linking Linkerbug ... # ./Linkerbug Loading object "b.o" Linkerbug: lookupSymbol failed in relocateSection (relocate external) b.o: unknown symbol `_defined_in_A' symbol resolution failed Loading object "a.o" symbol resolution ok Loading Haskell module "Main.hs" ok Running "Main.main" In B In A Segmentation fault: 11 }}} (with GHC 7.4.2, 7.6.3, 7.8.2, 7.8.3; OSX 64 bit). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 13:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 13:15:36 -0000 Subject: [GHC] #9481: Linker does not correctly resolve symbols in previously loaded objects In-Reply-To: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> References: <044.0f3c08e0d5a42fe8ecdcbe7daafad442@haskell.org> Message-ID: <059.6e5b5f8156d16aad2e0e7696bc714dd7@haskell.org> #9481: Linker does not correctly resolve symbols in previously loaded objects -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 14:09:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 14:09:24 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.3f54147fd3e51e06a4bbe388a248693c@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you for writing the [wiki:StaticValues] wiki page. It is extremely helpful. We should get it settled down before I can comment meaningfully about the implementation. * It would be tremendously helpful to partition the wiki page into three layers:[[BR]][[BR]] * '''Library code built on top of the primitives GHC provides'''. `Closure` fits here.[[BR]][[BR]] * '''Primitives that GHC provides, as seen by the programmer'''. I believe that the `static` language construct and `Static` type (abstract) fit here, along with `applyStatic`, and `unstatic`.[[BR]][[BR]] * '''How those primitives are implemented in GHC'''. I believe that `GlobalName`, `Ref`, and of course the constructors of `Static`, are part of the implementation, not part of the programmer-advertised API of the feature. Would it be possible to make that decomposition explicit? Doing so would require quite a bit of re-structuring, because at the moment the three layers are all mixed up together. * I see the need for `Ref` vs `Static`; the latter allows comosition; the former is just a code pointer. But I don't understand what `GlobalName` is doing, nor why `Static` needs two type parameters. All very mysterious. The major open issue, but one that it not treated head-on in the wiki page, is that of '''polymorphism'''. Polymorphism simply isn't discussed by the Cloud Haskell paper. This, for example, is fine: {{{ x :: Static ([Int] -> [Int]) x = static (reverse :: [Int] -> [Int]) }}} Everything is monomorphic, and we can send a code pointer of type `[Int] -> [Int]`. But should either of these be OK? {{{ y1 :: Static (forall a. [a] -> [a]) y1 = static reverse y2 :: forall a. Static ([a] -> [a]) y2 = static reverse }}} The former is somehow really what we want: we want to encapsulate a code pointer to the real, polymorphic, reverse function. But it's tricky becuase GHC (and Haskell) don't usually allow a type constructor applied a polytype, thus `Static (forall a. [a] -> [a])`. So unless we do something we'll probably end up with `y2`, and that is problematic because if we write it out in System F we'll see {{{ y2 :: forall a. Static ([a] -> [a]) y2 = /\a. static (reverse a) }}} so the argument to `static` hsa a free variable, namely `a`, that is not bound at top level. I ''believe'' (see #9429), that some CH users are somehow doing this: instantiate the polymorphic function at `Any`, and send that: {{{ y2 :: Static ([Any] -> [Any]) y2 = static (reverse Any) }}} Now at the other end, you use `unstatic` to get `[Any] -> [Any]`, and in some way I do not understand, convert it to `forall a. [a] -> [a])`. But all this `y2` stuf is clearly a Gross Hack, and one that becomes even clearer when we have overloaded functions like `sum :: forall a. Num a => [a] -> a`. Now the `y2` equivalent really isn't going to work. With explicit System F notation: {{{ z2 :: forall a. Num a => Static ([a] -> a) z2 = /\a \(d:Num a). static (sum a d) }}} Now the `(sum a d)` has a free ''value'' variable `d`, which is lambda bound, so now `static` really cannot work. Again what we really want is {{{ z1 :: Static (forall a. Num a => [a] -> a) z1 = static sum }}} I'll stop here for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 14:09:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 14:09:51 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.66ac3ad154190c6200a1db36fe69ea6a@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): See discussion in #7015 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 14:43:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 14:43:09 -0000 Subject: [GHC] #9454: Unregisterized builds failing due to multiple uniques assigned to same FastString In-Reply-To: <045.da312330814d158945afffd5d67b3478@haskell.org> References: <045.da312330814d158945afffd5d67b3478@haskell.org> Message-ID: <060.8360c601d5386286852ea47e2ad68204@haskell.org> #9454: Unregisterized builds failing due to multiple uniques assigned to same FastString -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.9 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: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D164| -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * differential: => https://phabricator.haskell.org/D164 * resolution: => fixed Comment: Fixed by: {{{commit 9a708d38c4491dfdf7f97c03e3ff6d482cbdd66e Author: Sergei Trofimovich Date: Mon Aug 18 21:45:11 2014 -0500 UNREG: fix PackageKey emission into .hc files }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 15:27:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 15:27:29 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.07b05f96be7c1b5006a884257db3d9fe@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #8935 Comment: More `environ` nightmares, with the added twist of the GHCi linker. The problem arises here in `PrelIOUtils.o`: {{{ 00000000000002b0 <__hscore_environ>: 2b0: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2b7 <__hscore_environ+0x7> 2b3: R_X86_64_PC32 environ-0x4 2b7: c3 retq }}} `-Dl` has the following to say about this: [edited slightly for readability] {{{ Rel entry 2 is raw( 0x2b3 0x3a00000002 0xfffffffffffffffc) lookupSymbol: looking up environ initLinker: start initLinker: idempotent return lookupSymbol: symbol not found `environ' resolves to 0x7ffff7039fd8 Reloc: P = 0x44f0e2f3 S = 0x7ffff7039fd8 A = 0xfffffffffffffffc }}} Now `environ` is too far away to use a PC-relative 32-bit reference, so the GHCi linker makes a jump island, but that's nonsense since `environ` isn't a function but rather a pointer to an array of C strings. But, also `0x7ffff7039fd8` isn't the ''right'' `environ` according to gdb: there is NULL there. What gdb thinks is `environ` (and my environment does actually appear there) is `0x7ffff7ffe140`... which is also too far away from the relocation site. I wonder how this all worked when you typed `System.Environment.getEnvironment` into GHCi 7.6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 15:46:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 15:46:42 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.9f360c9da2ec492dbb7b72131552c358@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here is the corresponding `-Dl` output when I build the snippet with 7.6: {{{ Rel entry 101325 is raw(0x323c63 0x113a700000002 0xfffffffffffffffc) lookupSymbol: looking up environ initLinker: start initLinker: idempotent return lookupSymbol: symbol not found `environ' resolves to 0x24af250 Reloc: P = 0x40429ca3 S = 0x24af250 A = 0xfffffffffffffffc }}} This time the linker found `environ` in the executable, which is good (as it's near where we load object files): {{{ rwbarton at morphism:/tmp/shl$ nm /tmp/shl/shl [...] 00000000024af250 V environ@@GLIBC_2.2.5 [...] }}} So, the problem must be that in 7.8 `internal_dlsym` is finding `environ` in one of the `openedSOs` before it gets to looking in the executable. Why does it not look in the executable first? Time to reread #8935 I guess... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 16:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 16:00:41 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.57bed753677af9ab176de21ab32c7b07@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #9186 => #9186, #9480 Comment: I think the patch to fix this (which has been reverted) would fix #9480, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 17:08:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 17:08:43 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.10775d9a912b6df63339eba7a8ca3363@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by agibiansky): You're right, I've confirmed that {{{ import System.Environment getEnvironment }}} causes the same issue. Thanks for looking into this! Is there any known workaround that can be used in client code? (i.e. can I fix this in any way in my own programs that use GHC API before 7.10 is released) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 17:15:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 17:15:41 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.e40507da4eeaddc3d2420b34327068c6@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by carter): on a mildly bikeshedding note, before this work (or applicable subsets) gets merged in, could we update the wiki notes etc to not use the term StaticValues? (this has been discussed elsewhere, but adding it as a note here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 17:23:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 17:23:04 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.cca8687a5635c31f8f6e0aae3a5fbbdb@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, build your program with `-dynamic`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 17:52:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 17:52:43 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.ea20838f680b96aff644e8ba887778f4@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase 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 nh2): Still pending. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 18:51:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 18:51:00 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.8e6b5faf25661d9d0bbd63efd5a0d4f5@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase 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 nh2): I added a test case at https://github.com/nh2/ghc/compare/testcase-8144. Please pull. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 18:56:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 18:56:58 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.6552af2998062070fa7793a3e4e7ebb9@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase 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 thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 21:40:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 21:40:09 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.fa85b2ddfe8fd3103a2bbf3312e9c59f@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by mboes): > * It would be tremendously helpful to partition the wiki page into three layers:[[BR]][[BR]] Thank you for this suggestion regarding structure. We will update the wiki page shortly. > * I see the need for `Ref` vs `Static`; the latter allows comosition; the former is just a code pointer. But I don't understand what `GlobalName` is doing, nor why `Static` needs two type parameters. All very mysterious. This should become clearer once we expand the scope of the wiki page. A quick primer: `GlobalName` is to `Ref` what `Addr#` is to `Ptr`. That is, just like `Ptr` is a wrapper around `Addr#` adding a phantom type parameter, so is `Ref` a wrapper around `GlobalName` adding a phantom type parameter. In our current scheme, `Static` is not a datatype defined in base. Only `Ref` is. `Static` is provided by an add-on package which already exists and that we are largely reusing: `distributed-static`. The only thing we have changed here is to make `distributed-static` parametric in the label type. Wherease `distributed-static` used to only support user strings as the label type, it is now parametric so that those users that are using Cloud Haskell on a current compiler (not supporting the `static` keyword extension), can still use the `distributed-static` package. That's where the `l` parameter in `Static l a` comes from: `l` is the label type. When using `static`, the label type is a `GlobalName`. When not using it, one typically uses a free form string. Or some custom datatype with one constructor per possible remotable function, if one prefers to in effect manually defunctionalize. > The major open issue, but one that it not treated head-on in the wiki page, is that of '''polymorphism'''. Polymorphism simply isn't discussed by the Cloud Haskell paper. > [...] > So unless we do something we'll probably end up with `y2`, and that is problematic because if we write it out in System F we'll see > {{{ > y2 :: forall a. Static ([a] -> [a]) > y2 = /\a. static (reverse a) > }}} > so the argument to `static` hsa a free variable, namely `a`, that is not bound at top level. I ''believe'' (see #9429), that some CH users are somehow doing this: instantiate the polymorphic function at `Any`, and send that: > {{{ > y2 :: Static ([Any] -> [Any]) > y2 = static (reverse Any) > }}} > Now at the other end, you use `unstatic` to get `[Any] -> [Any]`, and in some way I do not understand, convert it to `forall a. [a] -> [a])`. Yes, in this respect, we haven't changed anything to how `distributed- process` is already doing things today. Currently, `distributed-process` already uses the `Any` "hack" for a number of internal remotable functions. In fact Well-Typed developed an entire package to support this, called `rank1dynamic`. It has an implementation of first-order unification, so that on the remote end where say `[Any] -> [Any]` is expected, it is perfectly fine to send a function of type `[Int] -> [Int]`, because `isInstanceOf (typeOf x) (typeOf y) == True` if `x :: [Int] -> [Int]` and `y :: [Any] -> [Any]`. So while there was an effort to not upheave the status quo too much, that's not to say that we shouldn't. The crux of the issue is: a) no first class representations of polymorphic types, b) avoiding impredicative types, because the support for that in GHC is patchy at the moment AFAIU. > But all this `y2` stuf is clearly a Gross Hack, and one that becomes even clearer when we have overloaded functions like `sum :: forall a. Num a => [a] -> a`. Now the `y2` equivalent really isn't going to work. With explicit System F notation: > {{{ > z2 :: forall a. Num a => Static ([a] -> a) > z2 = /\a \(d:Num a). static (sum a d) > }}} > Now the `(sum a d)` has a free ''value'' variable `d`, which is lambda bound, so now `static` really cannot work. Again what we really want is > {{{ > z1 :: Static (forall a. Num a => [a] -> a) > z1 = static sum > }}} > I'll stop here for now. Yes. FWIW, in the current implementation, we don't allow unresolved constraints in the type of the body of a static form. We have discussed this issue at length, both internally and with Edsko and Duncan. At this point, we simply don't know how to deal with constraints well, though Edsko did share with us some ideas that from an earlier discussion with you. I'll try to dig out that email from somewhere. It's worth noting that all overloaded functions can be handled with some help from the user, as discussed on the wiki page (conceivably the compiler could do this automatically): {{{ data Dict c = c => Dict showD :: Dict (Show a) -> String showD Dict = show t1 = static showD -- this works. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 22:27:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 22:27:50 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.6f6431fa3e06c090a6b2167df162516b@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): OK so it sounds as if `Static` is 100% part of the library layer, and GHC knows nothing about it. That's fine; and will become clear when you re- structure. Concerning upheaving, my main goal is to have clean, well-designed primitives in GHC. I don't fully understand the `Any` business (e.g. how can it possible deal with polymorphic functions with more than one type parameter `forall a b. a -> b -> b`?), but it smells like a hack. And I don't want to enshrine a hack in GHC. Perhaps we could say, for now, that the argument of `static` must have no free type variables, just as it has no free term variables (other than top level constants). So, {{{ y1 :: forall a. Static ([a] -> [a]) y1 = static reverse }}} would be rejected, but {{{ y3 :: Static ([Any] -> [Any]) y3 = static reverse }}} would be accepted. Now you can continue to do your current hack in the library (pending a better solution for polymorphism), but the GHC part remains simple and clean. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 23:31:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 23:31:12 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.a09527af4189968d5295e80bbd3dbaad@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by diatchki): The `Note` about probability of collisions is in `Data.Typeable.Internal` just above the instances. It looks like we are done with this ticket, so I am going to close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 20 23:32:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Aug 2014 23:32:40 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.105a9847c638fe4bd2ee2684ead19d86@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: merge request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by diatchki): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 00:26:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 00:26:28 -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.e610fc5bb9326e0145b94481b501e437@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9282 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by int-e): I believe that this also affects users of 'cabal repl', because cabal- install uses -dynamic-too for compiling. So after 'cabal build', 'cabal repl' will still recompile all modules of a package as bytecode. With ghc-7.6.3 (and vanilla objects), 'cabal repl' would load the compiled object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 04:22:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 04:22:51 -0000 Subject: [GHC] #9482: Implementing Of Yoga For Bodyweight Reduction Message-ID: <049.cd319b8c60b0e1c07b70e2a4f8cff5f2@haskell.org> #9482: Implementing Of Yoga For Bodyweight Reduction -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- Forty or Banknote decades previously, a quite a few of group nonetheless failed to pair the true difference between Yoga and Food. Time, Yoga is so wide-spread that it can be mainly a blood statement. Yet it is rattling quite effectively set up time, it doesn't take that unspecialized open in fact understands what Yoga is. There ar[http://guiadecorpomagro.com/ Goji Slim]e copiousness of myths roughly Yoga which can be instructed by folks that do not possess a high representation nigh it. Yoga is so elaborated that it offers anything for apiece and every being who chooses to hold it. It would not urinate a disagreement should you be youthful, ancient, unwished fat, decrease, negotiable or meizitang, one and all can regain from some constitute of Yoga. Yoga was at basic affirm pleasure in the payback on a regular ground.Umpteen folks muse to classify Yoga as a unary accurate component, but that honourable exclusive isn't lawful. Its a lot of chiseled details, conditional on anything you are performing. Yoga is not really conscionable gymnastics, or upbeat schooling or perchance a implementation to grip your fat. It's also not simply shipway to inferior your anxiousness, speculate or be far statesman unworldly. Yoga is most of these issues unitedly with a rattling abstraction additional which you present not be sentient of. http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 05:09:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 05:09:45 -0000 Subject: [GHC] #9483: Lack Of Exercise - Sleep Walking To Obesity Message-ID: <049.6b9b5bcff4a5f5ab100762129c9d2714@haskell.org> #9483: Lack Of Exercise - Sleep Walking To Obesity -------------------------------------+------------------------------------- Reporter: carybennet | 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 have to take I've put on a considerable assets of metric over the old period and I cognize why. It's not because I've been feeding many, but rather travail little. [http://guiadecorpomagro.com/ Goji Slim] I've been writing added collection and my investigate has had me virtually affixed to the head in line of the computer and exclusive my intelligence and fingers know been deed a workout. That's my free, but not for much long as the assemblage is nearly through. The dopy artifact is I comprehend truly dreamy. I fuck rightful a few transactions training a day would really energise me and most promising excrete me writer successful. Nonetheless, I can't seem to aspiration myself inaccurate from the computer and see myself locution things suchlike, "I'll conscionable do this premiere", or I'll do it "subsequent", "tomorrow", "close period", and the abolitionist is I rightful harbour't done anything. It shows.I'm not exclusive though. According to the stylish BBC video interest, half the commonwealth instrument be weighty within the close twenty-five geezerhood. It give value the land something in the location of 45 1000000000000 pounds finished wellbeing issues and irrecoverable transform hours.Plainly, not everyone is penning a production so what's occurrence?Cured, it appears there's a lack of teaching as far as substance labelling is attentive and group are having a hard quantify determinant what's beatific or bad. Despite the authorities recommendation of a sagittiform interchange wanton method on packaging which understandably indicates ketamine is acceptable supermarket chains score adop http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 05:53:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 05:53:38 -0000 Subject: [GHC] #9484: Serious Health Issues Related To Excess Calorie Intake Message-ID: <049.2dd546ed4d3ee5319b841f4d40f31b7d@haskell.org> #9484: Serious Health Issues Related To Excess Calorie Intake -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- Anybody who is slightly adiposis or clinically weighty is ever on a hunting for shipway that can provide them injury their redundant pounds of fat. There are efficacious treatments that can confirm ministering, easily ready on the mart. Still, you should not opt for any dose without a priggish audience with a mountebank. [http://guiadecorpomagro.com/ Goji Slim] In the UK, fatness is movement a overserious health danger, as some half of the grownup universe is now fleshiness and active one somebody of these people are weighty. The capital movement of ascension obesity levels among fill is attributed to their progressively sedentary contemporary lifestyle. Also, you can easily get garish snack foods and inexpensive advanced fat bathroom meals that are mostly considered frail.If the clogging measures are not embezzled now, the day is not far away when fatness may prettify the major drive of preventable deaths and diseases among fill worldwide, overthrowing ventilation to second slot. According to the WHO, smoking is the stellar cause of preventable deaths and diseases among grouping worldwide. http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 06:27:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 06:27:29 -0000 Subject: [GHC] #9485: Jogging And Weight Loss Message-ID: <049.cad34dc989c3a573d617f3d1e8f28982@haskell.org> #9485: Jogging And Weight Loss -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- n improver to Supernumerary fat Experience We are able to sensing at lengthways, how hurried, the length of second, your sportsmen advanced additionally, the brobdingnagian feeling attained from this. BUT- lik[http://guiadecorpomagro.com/ Goji Slim]e everything there is a outset. That is what we should definitely instrument utter about--- jogging--- and the way Slimming Enclose spurting. The numerous advantages act equal operative: fat casualty as fortunate as management, weakened enunciate, a oecumenical a module of eudaimonia and condition as recovered as personally ferment into locomotion of pedagogy, if should flowing discolor to be jogging? Your deliberate shall be based on provided unique ordeals as healthy as outcomes. Any dilemma virtually what is strolling would most likely outline umpteen different results depending on multitude . The genuine set up athlete likely person an inflated basic versus the nonprofessional as a resultant of modification throughout abilities. Any unshared workout regime is leaving needs to be devised for anybody and then there should real be individual statistic commonwealth to hit success. The way to fantasy born outcome using a streetwise counsel. With far much identified stipulations, operative can be proposed for existence within a viii secondment klick when exertion to embellish over this good of happening, this is certainly the fuzy topic. It also are the soul calculated during touchable exertion-heart/pulse impeach time in the win along with the example required within the eliminating of these rates near culmination of this online occupation. There exists region for discussion-- for this writing, the total updates gift most sure move being fungible. We shall communicate of human http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 06:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 06:53:29 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.243f01d05f1af3e742775917f2a1eda8@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by kgardas): Tested on Solaris 11. It runs fine and fixes exactly the same issue like on MacOSX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 07:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 07:56:27 -0000 Subject: [GHC] #9486: Weight Loss - Getting The Habit Message-ID: <049.da5cda8327df13d150b901d14e9d6a52@haskell.org> #9486: Weight Loss - Getting The Habit -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- You pair you're overweight, but you don't suchlike to admit it. You eff you essential to move your habits. You know you could stance to oblige a unit sum system where you can effectively regress the coefficient for smashing. [http://guiadecorpomagro.com/ Goji Slim] You couple how you gained the coefficient, so why haven't you implemented a system where you can get rid of it? All you impoverishment to do is to read new habits and get rid of the old ones, change? Certain, you say, but it's not that dolabrate. Comfortably, in a sagaciousness that may be genuine, nonetheless, that doesn't link you can use that as an instance for not trying. You'd belike go on one of those fad diets quicker than you would a long- term arrangement that would stay off the unit permanently. Those fad diets may ameliorate you to slenderize thrown and get haggard quicker, but work what? After you stopover you go conservative sustain to where you were, gained coefficient and all. Those primary and fad diets licking the intend of a long-term, permanent weight red goal. Besides, when you use those diets, you end up not getting all of the calories you pauperism. In fact, you end up depriving yourself of ample calories necessary to have a counterpoised alimentation. You may lose whatever pounds, but as explicit earlier, the weight give proceed bet. Sometimes it travel http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 08:04:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 08:04:14 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.6050b8766519166fcabdb8139e386575@haskell.org> #8778: Typeable TypeNats -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: diatchki Type: feature | Status: merge request | Milestone: 7.10.1 Priority: normal | Version: 7.8.1-rc1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 4385 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): For completeness, the note is `Note [Potential Collisions in `Nat` and `Symbol` instances]`. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 08:52:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 08:52:15 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.bd73191ab41b5f3db3194c328fcc7af2@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 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 Iceland_jack): I removed some exported functions like `mapOL` (that only appears in a comment) and `foldrOL` and `foldlOL` (replacing occurrences with `Data.Foldable.foldr` and `Data.Foldable.foldl`. Other functions like (`concatOL`, `appOL`, `fromOL`, ...) could as well be dropped in favour of the `Monoid` and `IsList` methods in the future, but they are used substantially more than the ones I replaced so I decided against it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 09:04:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 09:04:13 -0000 Subject: [GHC] #9487: Safe Weight Loss: The Guaranteed Way To A New Slender You Message-ID: <049.b166b9ac13458745ee9f1ca84628acc1@haskell.org> #9487: Safe Weight Loss: The Guaranteed Way To A New Slender You -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- Did you bang that yo-yo fast (losing, then gaining, then losing coefficient and so on) is improbably bad for your eudaimonia? Your body vindicatory doesn"t see what"s achievement on. Freshman it has shortage, then spread, then deficiency again . . . and what"s statesman, t[http://guiadecorpomagro.com/ Goji Slim]his doings instrument cause your metabolism to lazy felled and interruption onto fat because your embody thinks there might be other famine on the way. So you"ll often end up consideration many than you did in the oldest position. I can"t articulate sufficiency the grandness of harmless weight going -- for both your upbeat and your image. The key to safe weight expiration is to fuck your quantify. Yes, I jazz, you deprivation to get slim like yesterday. But if you judge some it, wouldn"t you kinda be slim for sprightliness than go on some cast fasting, retrograde a lot of metric and put it all posterior on again? If you necessity to be small for swell, you"ll have to play mentation same a small someone, so that bit by bit the pounds fire off -- and this best abstraction to lie at is your lust versus your perceived drive. Unfeigned thirst is a really unique perception which you may eff forgotten how to know; if you"re a habitual over-eater you belike never let yourself get the mark of want so you don"t e'er comprehend it anymore. In that circumstance, it can be utilitarian to go without matter for half a day, ju http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 09:08:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 09:08:18 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.5bef8fa3c2184179af00116f008dcc10@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:22 simonpj]: > Perhaps we could say, for now, that the argument of static must have no free type variables, just as it has no free term variables (other than top level constants). > [...] > Now you can continue to do your current hack in the library (pending a better solution for polymorphism), but the GHC part remains simple and clean. Yes. It occurred to me while falling asleep last night that just as we ban qualified types, we could as well ban polymorphic types. In both cases, these features are "emulated" outside of the compiler (using the `Any` hack and a library implementation of unification in the case of polymorphic functions, passing an explicit `Dict` in the case of overloaded functions). Now, for the `Any` hack to continue working in full generality, we're back to #9429. > I don't fully understand the `Any` business (e.g. how can it possible deal with polymorphic functions with more than one type parameter `forall a b. a -> b -> b`?), but it smells like a hack. There are two ways to do this (see #9429): define {{{ type Any1 = Any type Any2 = Any Any }}} and then you can encode your type as `Any1 -> Any2 -> Any2`. Alternatively, Edwardk suggests `Any 1 -> Any 2 -> Any 2`, using type- level literals. I like that one better. Whatever we do, for the purposes of Cloud Haskell, it must be possible to have a `Typeable` instance for the resulting type. If `GHC.Exts.Any` becomes a type family, then that's no longer a possibility. See proposed solutions in #9429. No matter what we do there, ideally it should be possible to use the `Any` hack to handle a type like `forall a m. Dict (Monad m) => a -> m a`, for example. Defining a `MyAny :: Nat -> *` type for this purposes is an option, but will only work for type variables of kind `*` and in particular not work for this example. The nice thing about having ''some'' datatype with the same properties as GHC 7.8's `GHC.Exts.Any` (at least for open kinds, not closed kinds, which can't be dealt with), is that the user or libraries don't have to bother defining a proliferation of `MyAny`s, one for each open kind that gets used in the wild. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 09:24:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 09:24:35 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.001f75d48aea37fd060fe893d96373f0@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by edsko): I'm not following the details of the discussion here, but since I wrote rank1dynamic originally, I feel compelled to defend it and say "of ''course'' it's a hack, a proper solution wasn't available" :-) One thing to be aware of, though. Giving annotations such {{{ y3 :: Static ([Any] -> [Any]) y3 = static reverse }}} is okay, but only just: we have to be careful that the compiler doesn't start optimizing the definition for the specific case of the "ANY" type, which is intended as a type variable stand-in, but of course in actually isn't and the compiler might therefore make wrong decisions. In particular, have to be careful with dictionaries here. See "Word of Caution" at the end of http://hackage.haskell.org/package/distributed- static-0.3.0.0/docs/Control-Distributed-Static.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 09:45:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 09:45:26 -0000 Subject: [GHC] #9488: What Makes Green Coffee A Better Choice? Message-ID: <049.1f7f7de6354c6b6cc840a3b04cac1111@haskell.org> #9488: What Makes Green Coffee A Better Choice? -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- Greenish coffee has been gaining popularity as a preferred consumption in State for foregone several measure. After all, it has got most of what it takes to be a invigorating deglutition that relic crisp for a desire time, helps you get slimmer piece improving y[http://guiadecorpomagro.com/ Goji Slim]our central wellbeing. Site beverage Continent is a improved quality than stock seed for a class of reasons agnate of fact, coffee beans do not rest strong for a monthlong after they are cooked. It is not rightful with vegetable drink Country ?? green seed consists of un-roasted seed, Arabica beans in roasted gathering and several pct of chlorogenic pane. Chlorogenic solvent helps you earn a fitter health and throw few spare pounds with no broadside personalty. This flushed substance is nearly raped in routine drink, ketalar umber curbs the appetency and reduces craving for foods with flooding fat and treacly listing. he way river drinkable totality to substance its eudaemonia benefits is quite panduriform to realize, yet quite useful in producing the desired results. By patron tuberculosis of green brown State, sweeten is wrapped into the embody at a restrict http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 10:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 10:18:03 -0000 Subject: =?utf-8?q?=5BGHC=5D_=239489=3A_Trying_To_Fit_Into_Last_Year?= =?utf-8?b?4oCZcyBDbG90aGVz?= Message-ID: <049.4777cbe675c25c81b4499fdb20e08991@haskell.org> #9489: Trying To Fit Into Last Year?s Clothes -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- It's that quantify of the year again, when you bang that you fuck failed in your new year's closure to try and recede unit, and are panicking because you faculty pauperization to buy new clothes for the season. It is one of the most sad feelings to try on garment after garment in arrangement to reach something which does not excrete you sensing as tho' you are a sausage enwrapped up too dripless, all in vain. [http://guiadecorpomagro.com/ Goji Slim] We all act of the gathering ascertained that we testament relieve be competent to fit into stylish period clothes, arise summertime. Someways, the excesses of the season and the holidays ever achieve themselves matte at around this experience, when you are deed set to program shopping trips for your pass. It is so vexation to feat that the garment you bought exclusive live assemblage, now looks as tho' it belonged to someone two sizes small than you. This is when our thoughts channelise to quick fixes and accident fast, change though we live that they do not process in the nightlong run, and that we are vindicatory accomplishment to put the metric rearward on, as recovered as ruining our eudaimonia. Crash dieting, or any remaining shortly lived fasting and fad, present stomach its toll on your peel, text {people turning to nonfunctional surgery as the resolution to their coefficient problems. http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 10:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 10:25:26 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.73f9221642142fc25833febec64881dc@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by mboes): Indeed. In fact a recent issue was reported by Nick Smallbone against the released version of `rank1dynamic`, whereby using a custom `MyAny`-like datatype is causing problems, and the proposed fix is again to use `GHC.Exts.Any`: https://github.com/haskell-distributed/rank1dynamic/pull/7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 10:59:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 10:59:28 -0000 Subject: [GHC] #9490: Colon Detox To Lose Weight: Will It Actually Work? Message-ID: <049.7f021a2c34346ec163a90864e959c42b@haskell.org> #9490: Colon Detox To Lose Weight: Will It Actually Work? -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- o you greet to displace unnecessary pounds? If you're, you could jazz choson the cyberspace to look into weight reaction solutions. When few of us think slimming answer, slimming pills gift often be the opening abstraction that comes up. Patch fasting tablets could maybe work it easier [http://guiadecorpomagro.com/ Goji Slim]to complete your coefficient experience aims, weight release suppliments are not the only metric change fluid that you mightiness need to bump out. Infinite individuals hit efficiently elite aspinwall detoxifies, also proverbial as fat reaction cleanses, to lose the coefficient and you instrument likely greatest viscus detox to retrograde metric, there's lots of fill today, maybe just similar you, that proposal how the undivided apply functions. Before learning punctuation purifying may assist you recede metric, you penury to don't block that there strength be many variety of show. There are individual intestines detoxifies which push that they are intentional to aid you shed additional pounds. These kinds of colon detoxifies module also be illustrious as weightloss detoxifies. Having said that, there are metropolis detoxifies who publicize they are not promising to help you to disgorge artifact pounds, regularize though whatsoever of them can. http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 11:31:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 11:31:43 -0000 Subject: [GHC] #9491: Take It Off And Leave It Off Message-ID: <049.9b08fcdbdff892b924c25649eb3ed47a@haskell.org> #9491: Take It Off And Leave It Off -------------------------------------+------------------------------------- Reporter: carybennet | 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 status just cannot talk. Your weight is maturation into an release. Spell you are probably buying clothes that fit, you may be thought virtually your metric win a ripe bit. Fuck a wait at the weight loss tips provided below if you are wanting to eradicate this weight that has been burdening you for so endless. [http://guiadecorpomagro.com/ Goji Slim] One utile way of losing unit is to knob ingestion red meat. Red meats can advance to the assay of nonindustrial organs disease because they are highschool in cholesterin and soaking fat. Try insufficient meats instead of red meats. This includes seek and gallinacean.If your children are obesity, be trustworthy they get plentifulness of nap every period. Children cultivate the most as they death, which is when they also damage a humongous amount of calories. A growing male needs most digit hours of rest every period. Avow your kids how their bodies cultivate and why sleep is essential.If you are trying to get better, retard forth from the fashionable fad diets. Uttermost diets that focalize on curbing your nutritional intake might at oldest fast coefficient decline, but gift finally exclusive put your wellbeing in danger. Many fad diets materialize and terminate quickly in the metric deprivation field. They die out because tho' you may retrogress weight, the diet right isn't possible for your upbeat in the long run. http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 12:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 12:05:46 -0000 Subject: [GHC] #9492: Lida Weight Loss Capsules- The Only Message-ID: <049.a636a6896747c5534e942a2589c05c09@haskell.org> #9492: Lida Weight Loss Capsules- The Only -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- In this occupied experience tool fill hump metamorphose usual to swift matter habits, extendible excavation hours, laboring schedules, tensions to correspond deadlines fill tend to play many than their embody [http://guiadecorpomagro.com/ Goji Slim] can stomach. Fill don't symmetrical love instance to go for a stable fasting. So as an outcome group are gaining coefficient and comely weighty. And as mentioned above in this overbusy way no one has experience to go to the gym and create and bound unit. So now is there anything that can move to your deliver??? The Lida products are there to support you. Lida is the starring maker of metric decease capsules. Coefficient departure capsules, slimming capsules, fat burners all are tense to help you regular metric swiftly and smoothly. Coefficient experience capsules utilize on thermogenic transform which sensitise the metabolism and fasten the coefficient experience operation. A paper a day and you can see the conflict in one month. These capsules rush the body and fasten the metric experience machine by perfervid inordinate calories and other artefact that you make to cook http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 12:39:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 12:39:15 -0000 Subject: [GHC] #9493: Lida; A Great Help In Weight Lose Message-ID: <049.b0381310a052ce21e9dd911ec52e6ed9@haskell.org> #9493: Lida; A Great Help In Weight Lose -------------------------------------+------------------------------------- Reporter: carybennet | 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: -------------------------------------+------------------------------------- There are some weight losing methods exists these days. Grouping can operation and assert the assorted products that are recognise in the industry that helps in weight lose. However, the mortal abode to look these products is cyberspace. The websites employ people th [http://guiadecorpomagro.com/ Goji Slim] e assemblage nearly the equipments that is been laid downward to decoct unit without often difficultness. Grouping may also get careful near the brobdingnagian class methods of weight change. An Organization titled Lida DaiDaihua provides grouping with umpteen measures and steps for unit reduction. The particular benevolent of stuff of their commodity makes it easy for their consumers to severalize between their product. We should hold sufficient information around the methods of reaction weight and tools before we get any of the commodity.The method of coefficient reduction is rather inelastic. People may also modify this transmute an soft one by attractive different adenoidal worth tablets. Lida fasting pills are readily obtainable in the market time. Lida helps people reducing the weight by providing pills for reaction the metric and it also cater proposal to them for their diet package in prescript to serve them with their intake schedule. People with the desire of losing weight rattling ofttimes met Lida and the http://guiadecorpomagro.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 14:17:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 14:17:10 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.0c32a90c1ed7d36a8fbc73c425ece28c@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Igor, could you be so kind and update your code to be applicable to GHC HEAD? Absolutely best would be to use phabricator, but git/gnu patch will also do. I can't test since patch application fails badly here: {{{ $ gpatch -p1 < /tmp/dyson-libs.patch patching file libraries/unix/configure.ac Hunk #1 FAILED at 54. Hunk #2 FAILED at 219. 2 out of 2 hunks FAILED -- saving rejects to file libraries/unix/configure.ac.rej patching file configure.ac Hunk #1 succeeded at 857 (offset 54 lines). Hunk #2 FAILED at 894. 1 out of 2 hunks FAILED -- saving rejects to file configure.ac.rej patching file libraries/base/configure.ac Hunk #1 succeeded at 42 (offset 6 lines). patching file compiler/main/DriverPipeline.hs Hunk #1 FAILED at 1736. 1 out of 1 hunk FAILED -- saving rejects to file compiler/main/DriverPipeline.hs.rej patching file compiler/main/StaticFlags.hs Hunk #1 FAILED at 450. 1 out of 1 hunk FAILED -- saving rejects to file compiler/main/StaticFlags.hs.rej karel at silence:~/vcs/ghc-src/dyson-fix$ gpatch -p1 < /tmp/dyson-unix- libs.patch patching file libraries/unix/configure.ac Hunk #1 FAILED at 54. Hunk #2 FAILED at 219. 2 out of 2 hunks FAILED -- saving rejects to file libraries/unix/configure.ac.rej }}} that's with today's HEAD. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 14:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 14:46:32 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib Message-ID: <047.c599b15a57b1de1c882b98999535443e@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`. {{{ module Main where import qualified Codec.Compression.Zlib as Zlib import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Internal as BI import Control.Exception (bracket) import Control.Concurrent import Control.Monad import Control.Exception ( evaluate) import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package import Control.Concurrent.Async ( mapConcurrently) import System.Mem ( performGC ) import Debug.Trace test :: Int -> IO String test _ = do tid <- myThreadId -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100 -- Could also be replaced by: (BL.take (10^7) "/dev/urandom") dat <- BL.readFile "/tmp/testdata" let cbuf = Zlib.compress $ traceChunks tid $ dat s <- evaluate $ sha1 $ Zlib.decompress $ cbuf return $ show s where -- We used this to check whether buffers were reused by different threads, but that -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it -- harder to reproduce possibly because of scheduler effects. In a much larger program -- it could be reproduced more easily without the trace, but in this small example -- tracing seems to cause the right amount of nondeterminism. traceChunks tid bs = BL.fromChunks $ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..] $ BL.toChunks bs showBS (BI.PS ptr off len) = show ptr main = do r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int]) putStrLn $ show $ r where -- Regularly forcing the GC makes the test-case more reproducible. withGCThread io = bracket (forkIO $ forever $ performGC >> threadDelay 1000) killThread (const io) }}} The output should be something like: {{{ ... ThreadId 51:0x00000001091ee010 ThreadId 49:0x00000001091a7010 ... ThreadId 49:0x000000010986f010 zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check) }}} You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different. So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 14:52:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 14:52:11 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.530b9874ec7079d703eaa5577ca00e48@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | 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: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 17:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 17:01:45 -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.09fdce7ac8e2cf26a61581127fb0e049@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: | -------------------------------------+------------------------------------- Comment (by mpickering): I just tried out this patch and it seems strange to me that the constructor synonym has the same class constraints as the pattern. Is this by design? Here is an example which would have worked really nicely if not for this restriction. I know you can get around this by defining your own constructors with the right types. Note that there is no `View` instance for `Holey` which makes sense but we can still define a `Construct` instance. {{{ {-# LANGUAGE PatternSynonyms, ViewPatterns #-} data ExpF a = AddF a a | NumF Int deriving Show class Construct a where construct :: ExpF a -> a class View a where view :: a -> ExpF a newtype Exp = Exp (ExpF Exp) deriving (Show) instance Construct Exp where construct e = Exp e instance View Exp where view (Exp e) = e data Holey = Hole | NonHole (ExpF Holey) instance Construct Holey where construct = NonHole data AttrExpr = AttrExpr [String] (ExpF AttrExpr) pattern Add a b <- (view -> AddF a b) where Add a b = (construct (AddF a b)) pattern Num n <- (view -> NumF n) where Num n = (construct (NumF n)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 17:57:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 17:57:09 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady Message-ID: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment in the source: {{{ The foldr2/right rule isn't exactly right, because it changes the strictness of foldr2 (and thereby zip) E.g. main = print (null (zip nonobviousNil (build undefined))) where nonobviousNil = f 3 f n = if n == 0 then [] else f (n-1) I'm going to leave it though. }}} This rule is intended to allow `foldr2` to fuse with ''either'' argument list. There are thus two problems, one already documented and the other not: 1. The rule can turn working code into non-working code, although this seems to be ''relatively'' unlikely. (The problem the above example is showing is that if the left list ends at the same time the right list bottoms out, the world goes boom. So `foldr2 f [1,2,3,4] (1:2:3:4:undefined)` appears to be a problem. You could argue this is not a big deal, I suppose. 2. The `foldr2/left` and `foldr2/right` rules are not confluent. They are both active in all phases, but if both list arguments are good producers, they will each want to rewrite the expression differently. So if you actually care about which one fuses, you need to explicitly block fusion with one argument using `NOINLINE`, which of course could easily muck up some other optimization. My uninformed opinion: nix the `foldr2/right` rule, and change the documentation to indicate that `foldr2` fuses with its ''left'' argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 19:01:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 19:01: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.b7f6371a7ceb105ebd81536ba972d55c@haskell.org> #9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9132 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: => #9132 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 20:55:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 20:55:02 -0000 Subject: [GHC] #9496: Simplify primitives for short cut fusion Message-ID: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> #9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there appear to be two production primitives, `build` and `augment` (although I may have missed some). There are multiple consumption primitives (at least: `foldr`, `head`, `and`, `or`, `any`, and `all`). The rule sets for some producers seem to forget to handle `augment`, and the `augment/augment` rule is omitted as "true, but not, I think, useful". A number of other functions are instead rewritten into `foldr` forms, and then written back if they don't fuse. == What to do: == Personally, I'd be very tempted to start by saying `build g = augment g []` (or ''possibly'' even `build g = extend [] g []` if I can ever get that idea to work) and cut the problem in half. The main problem I see with this is if other people are importing `GHC.Exts` or `GHC.Base`, writing things with `build`, and expecting them to fuse. One way to deal with this, perhaps, is to hack a special rule into the RULES compiler to recognize `GHC.Base.build` on the LHS of RULES and replace it with the appropriate `augment` form, emitting a warning. Where to go after that: the question remains whether it's best in general to rewrite a form to `foldr` to make it fuse, or to fuse directly with `augment`. The answer presumably depends, at least in part, on whether there are additional `foldr`-based rules we may want to add that would take advantage of the effort put into the translation back from the `foldr` form. I would conjecture that most such rules we could want would go beyond what the RULES system actually can do. That said, if we can find a way to use `foldr` forms without the horrible pain of translating back from them, that would be a very good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 20:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 20:55:55 -0000 Subject: [GHC] #9496: Simplify primitives for short cut fusion In-Reply-To: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> References: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> Message-ID: <060.9fcb7a2b8fbb4e2fb7cb3777c63807ac@haskell.org> #9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 21:07:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 21:07:03 -0000 Subject: [GHC] #9497: Silent typed holes Message-ID: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: typed holes, | Operating System: warnings | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely end compilation. When writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous. I propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as- undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if "-fdefer-type-errors" was on, but ONLY for typed holes. This would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile "for real" I get an error about typed holes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 22:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 22:31:15 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files Message-ID: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> #9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 22:46:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 22:46:29 -0000 Subject: [GHC] #9499: Add -prelude-is flag Message-ID: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: flag | 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: -------------------------------------+------------------------------------- I would like GHC to have a `-prelude-is` flag, which would specify an alternate Prelude to use instead of the default Haskell prelude. The benefit this would have is that this would give alternate preludes a more first-class status. Instead of having to import an alternative prelude everywhere, you could just have a ghc-options: -prelude-is=... flag in your *.cabal file, and have a different prelude be used. This is important for my own work, as I highly prefer other preludes for my non- library development; I think this is a feature which will be very useful as Haskell develops and we try to figure out how to get rid of the warts in the current Prelude. Additional discussion here: https://groups.google.com/forum/#!topic /haskell-cafe/NCVzXZcxNmQ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 23:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 23:07:47 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable Message-ID: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: -------------------------------------+------------------------------------- I wanted to do this to turn -fsimple-list-literals on and off for NoFib without editing a million makefiles or recompiling GHC, but I bet there are other reasons. GHC's validate should probably prompt the user to verify they want to continue of the variable is set, and should issue a loud warning at the very end indicating what options were set by the variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 21 23:14:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Aug 2014 23:14:34 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.680cc380b61f4585ff94293586d2b9d2@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): An alternative would be to change the definition of `foldr2` (to check for the end of the right list first) and then eliminate the `foldr2/left` rule instead. I think that gives a slightly more consistent interface. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:17:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:17:50 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable In-Reply-To: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> References: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> Message-ID: <060.2e15e42a7cc4b0b718847469126688fa@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Might be simpler to just patch NoFib to read off an ENV Var for additional flags, have you dug into doing that? I'm happy to help you figure out a patch for that. Much simpler (and safer) than patching ghc to read off env vars always -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:18:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:18:44 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable In-Reply-To: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> References: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> Message-ID: <060.95d90a49014f61479e204183d7e34c83@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I think https://github.com/ghc/nofib/blob/master/mk/ghc-opts.mk is all you need to modify to change the flags passed everywhere -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:22:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:22:25 -0000 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> References: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> Message-ID: <061.e6945af89eb36da4e013280e5e973472@haskell.org> #110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: None | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by kfrdbs: Old description: > {{{ > A complete set of binaries for ghc and ghci under > cygwin would be really nice. > > Using the win32-version works, but is far from satisfying. > > GHCI does not recognize the arrow keys, thus no > command history (annoying errors instead) and I've > heard others complain about problem with linking, since > win32-ghc uses it's own gcc. > > I tried to compile ghc myself, but gave up after a few > hours. > > Please compile it and include it in cygwin's auto-update > system. > }}} New description: {{{ A complete set of binaries for ghc and ghci under cygwin would be really nice. Using the win32-version works, but is far from satisfying. GHCI does not recognize the arrow keys, thus no command history (annoying errors instead) and I've heard others complain about problem with linking, since win32-ghc uses it's own gcc. I tried to compile ghc myself, but gave up after a few hours. Please compile it and include it in cygwin's auto-update system. Test }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:23:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:23:51 -0000 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> References: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> Message-ID: <061.afc271c49089af24f96c859d8b61883f@haskell.org> #110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: None | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by kfrdbs: Old description: > {{{ > A complete set of binaries for ghc and ghci under > cygwin would be really nice. > > Using the win32-version works, but is far from satisfying. > > GHCI does not recognize the arrow keys, thus no > command history (annoying errors instead) and I've > heard others complain about problem with linking, since > win32-ghc uses it's own gcc. > > I tried to compile ghc myself, but gave up after a few > hours. > > Please compile it and include it in cygwin's auto-update > system. > > Test > }}} New description: {{{ A complete set of binaries for ghc and ghci under cygwin would be really nice. Using the win32-version works, but is far from satisfying. GHCI does not recognize the arrow keys, thus no command history (annoying errors instead) and I've heard others complain about problem with linking, since win32-ghc uses it's own gcc. I tried to compile ghc myself, but gave up after a few hours. Please compile it and include it in cygwin's auto-update system. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:24:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:24:20 -0000 Subject: [GHC] #9501: test Message-ID: <045.f63403362cf6f0029c4d9db554372aef@haskell.org> #9501: test -------------------------------------+------------------------------------- Reporter: kfrdbs | 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: -------------------------------------+------------------------------------- test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 02:26:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 02:26:44 -0000 Subject: [GHC] #9501: test In-Reply-To: <045.f63403362cf6f0029c4d9db554372aef@haskell.org> References: <045.f63403362cf6f0029c4d9db554372aef@haskell.org> Message-ID: <060.24161e7309d4591b0fb9279b5ff1e86f@haskell.org> #9501: test -------------------------------------+------------------------------------- Reporter: kfrdbs | 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 kfrdbs): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:10:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:10:48 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.1b86ba140adfa6d404a2698094fa806b@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Gabor Pali ): In [changeset:"030549a1e263f352814e982fd9dba77755326a03/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="030549a1e263f352814e982fd9dba77755326a03" Fix #9465. It turned out the sed(1) expressions are not fully portable. So revist my earlier attempt for getting GHC_LDFLAGS in the configure script and rewrite it in Perl instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:14:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:14:55 -0000 Subject: [GHC] #9500: Allow GHC defaults to be modified with an environment variable In-Reply-To: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> References: <045.8c4a73dd9f84bbbd2d69560ad3e1890f@haskell.org> Message-ID: <060.0e8baf1d222b3ba7e8798bdb8521ed41@haskell.org> #9500: Allow GHC defaults to be modified with an environment variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:15:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:15:58 -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.20f484fa17f3d4f47bd01b5d70a1cf12@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:21:44 -0000 Subject: [GHC] #9502: mapAccumL does not participate in foldr/build fusion Message-ID: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> #9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 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: -------------------------------------+------------------------------------- This can probably be fixed in much the same way as `scanl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:33:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:33:17 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.a7ef960bf040f1bd653be4d1ab511e90@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:7 jrp]: > (Exercise for the reader: do it in bash script :-)) For what is worth, doing this in pure {{{sh}}} would not be much more complicated... I should have thought about this earlier :-) > PPS: The patch executes OK. In an ideal world the test might come after the configure script > tests for perl (although, as you point out, the check is (presumably) redundant as you would not > have got that far without a perl boot. Indeed. I have checked it without Perl being in the {{{PATH}}} and {{{configure}}} failed okay. That is, although it did not find Perl when it tried to evaluate the expression, but it will say {{{configure: perl not found}}} -- and then at the check for Perl it will stop and display the corresponding error message ({{{You must install perl before you can continue...}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:34:50 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.b0c3e086ac46314a7de894c0f64c1676@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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 think that's a very reasonable suggestion. What would make sense to me is this: * `-XTypedHoles`, by default, generates ''warnings'' not ''errors''. * If you run a program that exhibits such warnings, you get the behaviour of `-fdefer-type-errors` (i.e. a runtime crash) * `-Werror` would make the warning into a fatal error, as usual. * We add a flag `-fno-warn-typed-holes` which switches off warnings if you don't want to see them. This is the part you are asking for. By treating this as "just another warning", we make it less of a special case. However the first point is, I believe, a change in behaviour; i.e. it makes a typed hole into a non-fatal warning by default, rather than a fatal error. To make it fatal you'd have to do `-Werror`, although that makes ''all'' warnings fatal. Does that seem like a reasonable change? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 07:41:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 07:41:05 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.04431e4351e1153d6754f8e1b43ab11e@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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 simonpj): I'm not against this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 08:25:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 08:25:00 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.5543f6ef49957e18c91b806c881d0f57@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): Sure, it will take some time, because I need to test both Linux and Dyson -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 08:46:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 08:46:09 -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.55e12dd6403499e42b1ed405ea6a9390@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: | -------------------------------------+------------------------------------- Comment (by simonpj): It's a bit hard to understand your example because you don't give any types, or any code that you think should work, but doesn't. But I ''think'' you mean this: the two directions of an explicitly- bidirectional pattern might have utterly different class constraints. After all, the two directions are specified by quite different code. Suppose that * Pattern `P` (used in a pattern) ''requires'' constraints `CR`, and ''provides'' constraints `CP` * Constructor `P` (used in an expression) requires constraints `CE` Then I think the only required relationship is this: `CP` must be provable from `CE` (since `CP` is packaged up in a P-object). Is this what you meant? Then indeed I think that we have not really discussed this possibility at all. There is a tricky UI issue, which is how to say when you ask `:info P`. And, worse still, what it would mean to give a type signature to `P`. So it looks to me, on first impression, that what you want is do-able and sensible. But there are some design issues to work out first. Let's see what Gergo has to say. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 08:59:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 08:59:44 -0000 Subject: [GHC] #9496: Simplify primitives for short cut fusion In-Reply-To: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> References: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> Message-ID: <060.b7b8acfa0ab239a46ffc7a2670c7258e@haskell.org> #9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: fusion 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): I believe that there are good reasons for distinguishing build and augment. [http://research.microsoft.com/en-us/um/people/simonpj/papers /andy-thesis.ps.gz Andy Gill's thesis] would be a good place to look. But perhaps one could do everything in terms of augment; I'm not sure. Worth a try. I think there is really only one primitive consumer, foldr. I thought we rewrote into foldr and then back. If that is not done for or, any, etc, I'm not sure why. Again, perhaps worth investigation. Certainly the original goal of the foldr/build paper was to say "ONE rule, not n*m rules". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 09:17:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 09:17:28 -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.a70ec774cb4fed153222012919f7d934@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: | -------------------------------------+------------------------------------- Comment (by mpickering): That is exactly what I mean, thank you for taking the time to clarify my comment. To once again be more specific, the code example I posted fails to type check with the following error message. {{{ fix.hs:27:14: Could not deduce (Construct a) arising from a use of ?construct? from the context (View a) bound by the type signature for Main.$WAdd :: View a => a -> a -> a at fix.hs:1:1 Possible fix: add (Construct a) to the context of the type signature for Main.$WAdd :: View a => a -> a -> a In the expression: (construct (AddF a b)) In an equation for ?$WAdd?: $WAdd a b = (construct (AddF a b)) fix.hs:30:12: Could not deduce (Construct a) arising from a use of ?construct? from the context (View a) bound by the type signature for Main.$WNum :: View a => Int -> a at fix.hs:1:1 Possible fix: add (Construct a) to the context of the type signature for Main.$WNum :: View a => Int -> a In the expression: (construct (NumF n)) In an equation for ?$WNum?: $WNum n = (construct (NumF n)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 10:50:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 10:50:17 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.cd69f55e050e09608d4b92ca2837326b@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Edsko my remark about a "hack" was not intended as a criticism. Of course, if GHC is inadequate you must hack around its shortcomings. My intent was solely this: let's not enshrine a temporary hack into the design of the language that GHC implements. There are two things going on in this ticket: * What should be the specification of the feature that GHC implements? I think we are agreeing that: the argument of `static` should have no free type variables. Let's put that into the spec.[[BR]][[BR]] That leaves open the question of adding an impredicative-like feature, the ability to have terms of type `Static (forall a. [a] -> [a])`, which make perfect sense, have no free type variables, but which are disallowed at present. * Given the above restriction, and the absence of the impredicative support, how can we hack around the restriction to get something like polymorphism. This is the `Any` discussion on #9429. Even lacking a fix for poly-kinded `Any`, it's not a disaster because for any particular kind we can always do the job; it's just a bit inelegant. If we agree about these things, perhaps you can update the wiki page as above and we can go from there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 11:16:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 11:16:28 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.700d9d7864528aaae68d7a362cfe50c3@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by edsko): One thing I was wondering about: clearly, solving the general problem of impredicativity would take us way off too far here; but if the type checker ''knows'' about static, just like, say, it knows about ADTs, then perhaps it wouldn't be too difficult to support things like `static (forall a. a -> a)`, just like it supports universally quantified types as arguments to ADT constructors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 12:20:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 12:20:04 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.cb40ee7125f2d75d434d14fcdebe3508@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Forbidding polymorphic types in the static form makes it less obvious defining a combinator like the following: {{{ staticCompose :: Static (b -> c) -> Static (a -> b) -> Static (a -> c) staticCompose sf sg = staticLabel (static (.)) `staticApply` sf `staticApply` sg }}} This is actually defined in the version of distributed-static in hackage: {{{ composeStatic :: (Typeable a, Typeable b, Typeable c) => Static ((b -> c) -> (a -> b) -> a -> c) composeStatic = staticLabel "$compose" staticCompose :: (Typeable a, Typeable b, Typeable c) => Static (b -> c) -> Static (a -> b) -> Static (a -> c) staticCompose g f = composeStatic `staticApply` g `staticApply` f }}} It doesn't mean that we can't live with the restriction, but we will have to figure out the impact upwards before committing, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 12:20:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 12:20:50 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.28ec08fef355c227f0c32317816d6564@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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: Phab:D171 | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D171 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 12:25:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 12:25:03 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.682ae34c2c4a96c1816f445823d2e133@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: Phab:D171 => Comment: I'm sorry I'm late to the conversation, but I wanted to remark that with GHC HEAD, there is an alternative implementation path to this feature, which is reusing the new module renaming support. Essentially, instead of saying `-prelude-is`, you can say `-package "base hiding (Prelude)" -package "my-prelude (MyPrelude as Prelude)"`. (Well, actually, the `hiding` modifier is not supported yet, but it wouldn't be hard to add.) Obviously this set of flags is longer, so `-prelude-is` might still be a handy shortcut, but an FYI! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 12:25:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 12:25:31 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.f698a3ebfd0b1772c95560e1c62de8b4@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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: Phab:D171 | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D171 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 13:36:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 13:36:30 -0000 Subject: [GHC] #9496: Simplify primitives for short cut fusion In-Reply-To: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> References: <045.ac67b2e89db14da0e2a7c577a8db7e03@haskell.org> Message-ID: <060.cc818e78c7c4486a1985158156722601@haskell.org> #9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: fusion 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 dfeuer): Replying to [comment:2 simonpj]: > I believe that there are good reasons for distinguishing build and augment. [http://research.microsoft.com/en-us/um/people/simonpj/papers /andy-thesis.ps.gz Andy Gill's thesis] would be a good place to look. But perhaps one could do everything in terms of augment; I'm not sure. Worth a try. > > I think there is really only one primitive consumer, foldr. I thought we rewrote into foldr and then back. If that is not done for or, any, etc, I'm not sure why. Again, perhaps worth investigation. > > Certainly the original goal of the foldr/build paper was to say "ONE rule, not n*m rules". > > Simon An aside: Just last night I saw a bit of the work Takano Akio has done on incorporating a worker/wrapper transformation into the framework (although I don't quite understand how it works yet). It doesn't seem to be quite ready for prime time (there were apparently some issues with one NoFib benchmark), but we might want to keep it in mind. I think the one rule concept is great. If that can be made to really work, that would be ''ideal''. Unfortunately, the need to wrangle the inliner as it currently works turns the one rule concept into an n*m-rule concept, where m is certainly at least 1, but currently 2 (the rewrite back rule clearly seems necessary for now?I don't yet understand things deeply enough to know for sure if the rewrite to rule is strictly necessary in all cases). I would speculate that the and/or/any/head/... rules came about because someone thought to themselves "There's only one [sic] consumer, `build`, so we can skip this difficult and invasive rewrite to/from process and just fuse with `build`. That's easy!" Well, they were a little wrong, but I'm not sure they were very wrong. I haven't had a chance to read the thesis yet, but from a purely practical perspective, I don't see any difference between `build g` and `augment g []`. I don't ''think'' anyone's tossing around partially applied `augment`s or anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 13:52:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 13:52:26 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.d27aacda35dc608d7503c8e305daf306@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: simonmar AndreasVoellmy | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4748f5936fe72d96edfa17b153dbfd84f2c4c053/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4748f5936fe72d96edfa17b153dbfd84f2c4c053" Revert "rts/base: Fix #9423" This should fix the Windows fallout, and hopefully this will be fixed once that's sorted out. This reverts commit f9f89b7884ccc8ee5047cf4fffdf2b36df6832df. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 13:58:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 13:58:54 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.267d90f9b55a7768ca430bd1d0d6fe43@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: simonmar => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 14:00:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 14:00:29 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.7b5ddf6947cbdc57e5bdc92b808ec278@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: infoneeded Type: task | Milestone: 7.10.1 Priority: lowest | Version: 7.9 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 rwbarton): Can we keep `foldlOL` and `foldrOL`? The GHC source tends to prefer monomorphic functions over polymorphic ones when the polymorphism is not needed. (See for example Simon's email [http://www.haskell.org/pipermail /ghc-devs/2014-August/006081.html here].) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 15:53:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 15:53:49 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.32582e0aecd61ac4e8a9f5ad9d24e823@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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: Phab:D171 | -------------------------------------+------------------------------------- Comment (by agibiansky): ezyang, if I implement this using the module renaming support, will that work if the new prelude `MyPrelude` isn't in a package? For example, if I just have two files named `A.hs` and `B.hs`, the current implementation allows you to write `ghc -prelude-is A B.hs` to use the module `A` as a prelude, even though you have no package structure at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 16:15:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 16:15:45 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.c38b9d78ea0d1fdb3e80af6e6857ed47@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: flag 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: Phab:D171 | -------------------------------------+------------------------------------- Comment (by ezyang): Not out of the box, but there is a related feature we're planning on adding which is `-alias MyPrelude Prelude`, which gives a module from any package another name. Of course, you could also just name your local file `Prelude`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 17:01:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 17:01:08 -0000 Subject: [GHC] #9503: Cross compiling with mingw uses wrong gcc Message-ID: <049.7b27da8a927dac07924f145126734a78@haskell.org> #9503: Cross compiling with mingw uses wrong gcc -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Greetings, I tried to cross compile a cross compiler ghc on Debian jessie Linux/GNU i386. I configured with "./configure --target=x86_64-w64-mingw32" (log attached). The configure script runs and then wants to use the native gcc (/usr/bin/gcc) instead of the mingw one (/usr/bin//usr/bin/x86_64-w64-mingw32-gcc). Thus the mingw headers (in /usr/x86_64-w64-mingw32/include/) aren't found, which leads to errors during compiling (relevant part attached). Regards Sven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 18:30:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 18:30:19 -0000 Subject: [GHC] #9503: Cross compiling with mingw uses wrong gcc In-Reply-To: <049.7b27da8a927dac07924f145126734a78@haskell.org> References: <049.7b27da8a927dac07924f145126734a78@haskell.org> Message-ID: <064.ac00a84f59e71ed37f2061e392141033@haskell.org> #9503: Cross compiling with mingw uses wrong gcc -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Cross compiling Resolution: | Architecture: x86 Operating System: Linux | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, this seems to happen for all cross-compilations, I don't understand it either. As a workaround you can explicitly specify `--with-gcc=...`, though, and that should at least get you farther. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 19:17:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 19:17:09 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive Message-ID: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: -------------------------------------+------------------------------------- At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation there is written > It [a memory load/store] is very rarely of the form: > {{{ > x = Sp + 8 > I64[x] = ... > }}} > And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety. In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address. But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 19:17:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 19:17:48 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.e2a309a34c38cbdd5b6c0aa922783e2a@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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): I don't feel strongly, but I'm -1 on defaulting to a warning over an error. It seems to invite the possibility that holes could make their way into released code, which sometimes has plenty of warnings. It's easy for a distribution tool to check for (and prohibit) `-fdefer-type-errors`, but it would be much harder to avoid holes under the proposed change. I also have to say that the current interface to this feature is very confusing! The flag `-fwarn-typed-holes`, on by default, causes '''errors''' to be reported, not warnings. And, the inverse, `-fno-warn- typed-holes` changes the nature of '''error''' messages, once again, as opposed to suppressing warnings, the usual behavior of `-fno-warn-...` flags. These flags are described in the "Warnings" section of [http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html the flag reference], rather misleadingly. To be concrete, I propose the following: * By default, holes behave exactly as they do now. * A new flag, `-fdefer-typed-holes` turns typed-hole errors into warnings, just like `-fdefer-type-errors` (which would imply `-fdefer-typed-holes`). * Re-appropriate `-fno-warn-typed-holes` to suppress the warnings generated by `-fdefer-typed-holes`. The current behavior of `-fno-warn- typed-holes` (to turn the usage of holes into out-of-scope errors) would no longer be available. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 19:17:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 19:17:55 -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.6f5da3f7031697807ae2ca78d8a995a0@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.3 (LLVM) | Keywords: fannkuch-redux Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9504 Type of failure: Incorrect | Related Tickets: #5567 result at runtime | Test Case: fannkuch- | redux | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * blockedby: => 9504 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 19:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 19:45:05 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.51341ec7c20ab69c9739c5438b18d960@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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 merijn): I would prefer the behaviour proposed by goldfire (or some variation of that), that is, I believe TypedHoles should be fatal by default and only optionally non-fatal. I have no opinion on eliminating the current "-fno-warn-typed-holes", if it stays and we get "-fsilent-typed-holes" or something similar, I would be satisfied too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 20:12:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 20:12:40 -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.400a90a9c04f6e5e48069d3d4a5f3944@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: ekmett Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: fixed | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 20:13:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 20:13:11 -0000 Subject: [GHC] #8899: StdGen does not generate 0 In-Reply-To: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> References: <050.9a92435e95a80e8b6341c205b9d79461@haskell.org> Message-ID: <065.1208b106636c78c8ff7cdbd4a8617e06@haskell.org> #8899: StdGen does not generate 0 -------------------------------------+------------------------------------- Reporter: | Owner: ekmett novadenizen | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: | Keywords: libraries/random | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 20:14:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 20:14:38 -0000 Subject: [GHC] #7379: rangeTest test fails on Windows In-Reply-To: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> References: <044.9b565a502fad9bf85284cbdac833fae9@haskell.org> Message-ID: <059.d5eef65a4ad2c7ea4c4dafc2a538a1d5@haskell.org> #7379: rangeTest test fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/random | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 20:56:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 20:56:44 -0000 Subject: [GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() In-Reply-To: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> References: <053.e8acf5848af840b0d031e42250745cb2@haskell.org> Message-ID: <068.6bf36ac0da444d289a08906f7eddc493@haskell.org> #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: | Owner: AndreasVoellmy | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: MacOS X | Blocked By: Type of failure: Incorrect | Related Tickets: 9284 result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D129 | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): Are there ticket numbers for the "Windows fallout" stuff? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 21:25:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 21:25:56 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.d22f34c40ec4ece0be8e3eee04afa2b1@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.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 dfeuer): Even more kinds of producers makes for even more fusion rules. If we decide to rewrite ''all'' consumers to `foldr`, I suppose that then opens up the possibility of having multiple producers instead, but expanding on both ends makes for a rule explosion. I'm also trying, on and off, to see if we can get away with writing all these enumerations using `unfoldr` or similar; I'm not sure how these ideas interact. An idea that might be crazy: introduce a local annotation indicating that a certain function should be treated as `CONLIKE` at a particular call site. So then you'd have just `{-# CHEAP #-} build blah` and leave the fusion rules alone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 22:22:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 22:22:36 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.1dc51241fbbb474de7b9079b347ee800@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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): Crumbs, you are right. I'd forgotten that we'd decided ''not'' to make typed holes into a language extension (see [http://www.haskell.org/pipermail/ghc-devs/2014-January/003758.html this email]), but rather controlled by `-fwarn-typed-holes` which is on by default. I agree with Richard that this is jolly confusing. Two issues with Richard's proposals: * There is no way to switch off typed holes altogether, and revert to {{{ Hole.hs:1:7: Pattern syntax in expression context: _ }}} Maybe that is OK. * What does `-fno-warn-typed-holes` do in the absence of `-fdefer-typed- holes`? No-op with a warning? * What does `-fwarn-typed-holes` do? Perhaps just re-enable the warning after switching off all warnings with `-w`. Modulo just specifying (and documenting) this behaviour, I'd be content with the above. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 23:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 23:14:33 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR In-Reply-To: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> References: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> Message-ID: <059.f0c3f6bab927a797584745dfa0c32145@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/unix | 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 thomie): * status: new => patch Comment: Note: you will probably get a faster response if you submit a pull request here: https://github.com/haskell/unix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 22 23:38:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Aug 2014 23:38:40 -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.58cbcb03a2ce1b5983b10823b738cd4f@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Incorrect | hour) result at runtime | Blocked By: Test Case: | Related Tickets: #8293 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: thomie => * status: closed => new * resolution: fixed => Comment: Hello, the test is still failing for me, using GHC HEAD and the latest version of unix: {{{ =====> user001(normal) 5 of 29 [0, 0, 0] cd . && '/5playpen/t-edyang/ghc-master/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd . && ./user001 >user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./user001.stdout 2014-08-22 23:28:41.969906580 +0100 +++ ./user001.run.stdout 2014-08-23 00:33:07.631841764 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) Unexpected results from: TEST="user001" }}} On my box, running the following C program in terminal returns null: {{{ #include #include int main() { printf("%p\n", getlogin()); } }}} This StackOverflow post suggests that getlogin works quite unreliably: http://stackoverflow.com/questions/4785126/getlogin-c-function-returns- null-and-error-no-such-file-or-directory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:07:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:07:12 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals Message-ID: <046.095a614b9437d6cfe76c234b07042878@haskell.org> #9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | 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: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:07:31 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals (was: Bounded instance for Word (and possibly others) uses unboxed literals) In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.194c523f38846a78bc80350da9a4619e@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:13:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:13:29 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.fb096d083c3ebc4dcd229576a1ca0c10@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:38:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:38:12 -0000 Subject: [GHC] #9506: Name libraries (dll/so) separately from linker symbols Message-ID: <045.be873a58d95f2254770e54725ac4fac9@haskell.org> #9506: Name libraries (dll/so) separately from linker symbols -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- Tracking ticket so I don't forget. Based on feedback on `#ghc`, it sounds like it would be helpful if library names on the file system only had their full package name, e.g. `libHScontainers_HASH.so` as opposed to the abbreviated package name. Additionally, it seems less necessary to provide the abbreviated package name in linker symbols, since the modules often give a pretty good clue (and the package key can be looked up.) So let's do this, and make things better for users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:38:55 -0000 Subject: [GHC] #9507: ghc-pkg mode to query by package-key Message-ID: <045.94e3570469ccb8429301ef11591de043@haskell.org> #9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.9 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: -------------------------------------+------------------------------------- Right now, ghc-pkg understands package names and IPIDs. It should support package keys too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:39:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:39:48 -0000 Subject: [GHC] #9508: Rename package key Message-ID: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- We were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 00:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 00:53:45 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.8337471021015205b29a9b03ed6599c0@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by rodlogic): What is the problem with package key? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 01:23:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 01:23:39 -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.0874ab5e2c1ec10bfc01030b64350096@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Incorrect | hour) result at runtime | Blocked By: Test Case: | Related Tickets: #8293 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): @ezyang: which terminal emulator are you using? Does it work with `xterm`? Maybe we should change the signature of `getLoginName` to: {{{ getLoginName :: IO (Maybe String) }}} , since the man page explicitly mentions that [http://linux.die.net/man/3/getlogin getlogin] can return NULL: {{{ getlogin() returns a pointer to a string containing the name of the user logged in on the controlling terminal of the process, or a NULL pointer if this information cannot be determined. }}} The same applies to `getGroupEntryForID`, ticket #8293. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 03:41:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 03:41:26 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR In-Reply-To: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> References: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> Message-ID: <059.99e676aab786333afa28f009e9a5cacb@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/unix | 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 iquiw): Submitted PR. https://github.com/haskell/unix/pull/11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 03:52:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 03:52:55 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.c781e79f521a46495981807cf57d78e4@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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): Replying to [comment:4 simonpj]: > Two issues with Richard's proposals: > > * There is no way to switch off typed holes altogether, and revert to > {{{ > Hole.hs:1:7: Pattern syntax in expression context: _ > }}} > Maybe that is OK. I think this is OK. It's conceivable that a user makes a typo in an identifier that begins with an underscore and will be very confused by the error message. But, that exact same scenario would happen today, unless the user also somehow knows to use an obscure compiler option (`-fno-warn- typed-holes`). One way to mitigate this problem is to have typed-hole error/warning messages link to a description of the feature. > > * What does `-fno-warn-typed-holes` do in the absence of `-fdefer- typed-holes`? No-op with a warning? > It suppresses typed-hole warnings, of which there would be none. This is the same behavior as other `-fno-warn-...` options, when the condition that is being suppressed doesn't happen. I'm not bothered here. > * What does `-fwarn-typed-holes` do? Perhaps just re-enable the warning after switching off all warnings with `-w`. Yep. One issue with this bikeshed color: having options `-fdefer-type-errors` and `-fdefer-typed-holes` forced users to remember the difference between `type` and `typed`. I think the choices here make sense (`type` in the first, `typed` in the second), but it is a little annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 05:50:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 05:50:00 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 Message-ID: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | 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: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the GHC manual, any uses of an imported definition that is overloaded and INLINABLE will automatically cause a SPECIALIZE to be generated for those uses, if appropriate. However, this no longer appears to be the case in 7.8(.3). Here is a simple test case: {{{#!hs module A (foo) where import Data.IORef foo :: Ord a => a -> IO a foo x = newIORef x >>= readIORef >>= \y -> case compare x y of LT -> return x ; _ -> return y {-# INLINABLE foo #-} }}} {{{#!hs module Main (main) where import A main = foo (5 :: Int) >>= print }}} `foo` is constructed to be long enough that GHC 7.8.3 will elect to not inline it. When compiling with 7.6.3, the core contains the following: {{{ Main.$sfoo1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 55 30}] Main.$sfoo1 = \ (x_XkE :: GHC.Types.Int) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.newMutVar# @ GHC.Types.Int @ GHC.Prim.RealWorld x_XkE eta_B1 of _ { (# ipv_amT, ipv1_amU #) -> case GHC.Prim.readMutVar# @ GHC.Prim.RealWorld @ GHC.Types.Int ipv1_amU ipv_amT of ds1_amJ { (# ipv2_Xn8, ipv3_Xna #) -> case x_XkE of wild_axu { GHC.Types.I# x#_axw -> case ipv3_Xna of _ { GHC.Types.I# y#_axA -> case GHC.Prim.<# x#_axw y#_axA of _ { GHC.Types.False -> ds1_amJ; GHC.Types.True -> (# ipv2_Xn8, wild_axu #) } } } } } Main.$sfoo :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] Main.$sfoo = Main.$sfoo1 `cast` ( -> Sym <(GHC.Types.NTCo:IO )> :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)) ~# (GHC.Types.Int -> GHC.Types.IO GHC.Types.Int)) ... ------ Local rules for imported ids -------- "SPEC A.foo [GHC.Types.Int]" [ALWAYS] forall ($dOrd_sxj :: GHC.Classes.Ord GHC.Types.Int). A.foo @ GHC.Types.Int $dOrd_sxj = Main.$sfoo }}} However, in 7.8.3 and newer (I'm actually using 7.9.20140725 for this particular output, but 7.8.3 is similar), we see the following: {{{ Main.main1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 100 0}] Main.main1 = \ (s_aIb :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ((A.foo @ GHC.Types.Int GHC.Classes.$fOrdInt Main.main2) `cast` (GHC.Types.NTCo:IO[0] _R :: GHC.Types.IO GHC.Types.Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)))) s_aIb of _ [Occ=Dead] { (# ipv_aIe, ipv1_aIf #) -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout (GHC.Show.$fShowInt_$cshow ipv1_aIf) GHC.Types.True ipv_aIe } }}} There is no local rules section in 7.8.3. Putting a manual SPECIALIZE pragma in the main module generates comparable code to 7.6.3, so it does not appear to be a failure at that level. Rather, GHC seems to just not be generating the SPECIALIZE equivalent. Presumably this is a regression, but even if not, the manual should be revised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 11:52:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 11:52:11 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.835212a5c43f9884dcb76fcb3a99990c@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: | Owner: jjaredsimpson | Status: infoneeded Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: Prelude | 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: | -------------------------------------+------------------------------------- Comment (by Scott Turner): The early answer, If the real part of y is positive, then the result should be 0. If the real part is negative, then the result should be Infinity. If y is imaginary, the result should be NaN. {{{ Infinity ** y = 0 ** (negate y) }}} provides the basis for a satisfactory solution. One improvement is to take Yalas's recommendation regarding NaN!**0. In code, the implementation is {{{ x ** y = case (x,y) of (_ , (0:+0)) -> 1 :+ 0 ((0:+0), (re:+_)) | re > 0 -> 0 :+ 0 | re < 0 -> inf :+ 0 | otherwise -> nan :+ nan ((re:+im), y) | (isInfinite re || isInfinite im) -> case y of (exp_re:+_) | exp_re > 0 -> inf :+ 0 | exp_re < 0 -> 0 :+ 0 | otherwise -> nan :+ nan (x, y) -> exp (log x * y) where inf = 1/0 nan = 0/0 }}} Regarding the questions raised in the earlier discussion: Q: What to do about the other operations than !**? A: That should be a separate bug report. Q: special case for raising to 1 to increase accuracy A: Addressed in the earlier discussion. Q: Do we need some tests? A: See examples below. Q: why we want to handle infinity!**0 and don't want to handle infinity!**y or x!**infinity? A: We do handle infinity!**y. For x!**infinity, the returned value is NaN:+NaN. The above patch could be refined using a directional interpretation of complex infinities, i.e. Infinity:+0, Infinity:+Infinity, 0:+Infinity, -Infinity:+0, etc. would each yield different results, and the result would also depend on log x. To some extent that might be managed by revising the exp function. It gets fiddly so I recommend making the above improvement, and leaving x!**infinity for another day. '''Examples''' || ||=existing =||=patched =||=Wolfram Alpha =|| ||0 !** 2 ||NaN :+ NaN ||0.0 :+ 0.0 ||0 || ||0 !** 0 ||NaN :+ NaN ||1.0 :+ 0.0 ||indeterminate || ||0 !** -2 ||NaN :+ NaN ||Infinity :+ 0.0 ||complex infinity || ||inf:+0 !** 2 ||NaN :+ NaN ||Infinity :+ 0.0 ||infinity || ||inf:+0 !** 0 ||NaN :+ NaN ||1.0 :+ 0.0 ||indeterminate || ||inf:+0 !** -2 ||NaN :+ NaN ||0.0 :+ 0.0 ||0 || ||-1 !** 0.5 ||6.12e-17 :+ (-1.0) ||6.12e-17 :+ (-1.0) ||0:+1 ||Note 2|| ||0 !** (1:+1) ||NaN :+ NaN ||0.0 :+ 0.0 ||0 || ||0 !** (0:+1) ||NaN :+ NaN ||NaN :+ NaN ||indeterminate || ||nan:+0 !** 0 ||NaN :+ NaN ||1.0 :+ 0.0 ||indeterminate || ||1 !** inf:+0 ||NaN :+ NaN ||NaN :+ NaN ||indeterminate || ||1 !** nan:+0 ||NaN :+ NaN ||NaN :+ NaN ||indeterminate || ||2 !** (inf:+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||2 !** (inf:+0) ||NaN :+ NaN ||NaN :+ NaN ||infinity || ||2 !** ((-inf):+0) ||NaN :+ NaN ||NaN :+ NaN ||0 || ||2 !** ((-1000000000):+1) ||0.0 :+ 0.0 ||0.0 :+ 0.0 ||..... || ||(0.8:+0.8) !** inf:+0 ||NaN :+ NaN ||NaN :+ NaN ||complex infinity || ||(0.8:+0.6) !** inf:+0 ||NaN :+ NaN ||NaN :+ NaN ||indeterminate || ||(0.8:+0.4) !** inf:+0 ||NaN :+ NaN ||NaN :+ NaN ||0 || ||(0.8:+0.8) !** (-inf):+0 ||NaN :+ NaN ||NaN :+ NaN ||0 || ||(0.8:+0.6) !** (-inf):+0 ||NaN :+ NaN ||NaN :+ NaN ||indeterminate || ||(0.8:+0.4) !** (-inf):+0 ||NaN :+ NaN ||NaN :+ NaN ||complex infinity || ||(0.8:+0.8) !** (inf:+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||(0.8:+0.6) !** (inf:+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||(0.8:+0.4) !** (inf:+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||(0.8:+0.8) !** ((-inf):+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||(0.8:+0.6) !** ((-inf):+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || ||(0.8:+0.4) !** ((-inf):+1) ||NaN :+ NaN ||NaN :+ NaN ||Note 1 || Note 1: Wolfram Alpha simplifies (infinity+i) to infinity, and as a result it misses the point of the indicated examples. Note 2: The ghc result for -1!**1/2 is somewhat unexpected due to the implementation involving complex log and an intermediate value of pi*i which of course is not represented with perfect accuracy. If this is a problem, it is not the one we are addressing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 14:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 14:57:10 -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.c37362b920a5ea8612dade1eea87d8be@haskell.org> #1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Easy (less than 1 Type of failure: Incorrect | hour) result at runtime | Blocked By: Test Case: | Related Tickets: #8293 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): From a cygwin terminal, I am moshed into a screen session. I can't easily test xterm because I don't have X forwarding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 14:57:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 14:57:19 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.462873257b1d8c0712fe14ab2f61310d@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by ezyang): Simon Marlow quite dislikes it, because it implies that it is the "primary key" to the package database, but it actually isn't: the primary key of the package database is the installed package ID. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 19:37:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 19:37:38 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.49deb71d7d663c624526b84b3970f4f9@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: patch Type: bug | Milestone: 7.8.4 Priority: normal | Version: 7.8.3 Component: | Keywords: fusion libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: David.Feuer@? (added) * version: 7.8.2 => 7.8.3 * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 21:50:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 21:50:03 -0000 Subject: [GHC] #9510: Prelude.!! is not a good consumer Message-ID: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> #9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think we can probably do something like this, but I haven't checked the Core yet: {{{#!hs xs !! n | n < 0 = error "Prelude.!!: Negative index" | otherwise = foldr go (error "Prelude.!!: index too large or list empty") xs n where go x _ 0 = x go _ f k = f (k - 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 21:59:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 21:59:21 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.4a2a6f9c7bb1b662becbd21175b82ce6@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 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 rwbarton): Somehow I'm unable to reproduce this with ghc 7.8.1, 7.8.3 or HEAD and attoparsec 0.11.1.0. Anyone have specific instructions? Maybe I am using the wrong version of some other dependency? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 23 22:18:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Aug 2014 22:18:32 -0000 Subject: [GHC] #9510: Prelude.!! is not a good consumer In-Reply-To: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> References: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> Message-ID: <060.ece437d149ec1b9913a60ec9d6c61189@haskell.org> #9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: fusion 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): Note that, like the new `last`-as-`foldl`, this almost certainly won't be able to unbox the list elements, for the same reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 03:42:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 03:42:20 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.6e56fed1fcb986211ea1e893573f867a@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => highest * milestone: => 7.8.4 Comment: I'm elevating the priority because it causes an ''undocumented'' reduction in laziness depending on optimization flags. Changing the documentation would lower the priority. Note: if eliminating the DWIM non-confluent rules is considered too much of a breaking change, we can fix the semantics, at least in part, by changing the baseline definition of `foldr2`, and making sure the documentation matches. Specifically, make the first base case look like {{{#!hs foldr2 c n [] ys = ys `seq` n }}} I'm not sure if the rewritten version will end up with the ''same'' semantics, but I'm pretty sure it won't be ''less'' defined, which is the current situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 05:25:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 05:25:40 -0000 Subject: [GHC] #9511: Remove deprecated -fglasgow-exts from NoFib suite Message-ID: <045.3f3d2a7f378761f15760d3cbe0670cbf@haskell.org> #9511: Remove deprecated -fglasgow-exts from NoFib suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: low | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 05:49:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 05:49:20 -0000 Subject: [GHC] #5813: Offer a compiler warning for failable pattern matches In-Reply-To: <047.b27cb5107d31276adbfc86c1613f2390@haskell.org> References: <047.b27cb5107d31276adbfc86c1613f2390@haskell.org> Message-ID: <062.2bf0b37eb4fa9518e07969d547d52fdb@haskell.org> #5813: Offer a compiler warning for failable pattern matches -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.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 merijn): * cc: merijn@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 06:53:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 06:53:56 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.775fd3695d8fc185bec257a01594217c@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): The root of all this is the asymmetry of {{{ Prelude> zip [] undefined [] Prelude> zip undefined [] *** Exception: Prelude.undefined }}} So what does the report say? It defined `zip` via `zipWith`: {{{ zipWith :: (a->b->c) -> [a]->[b]->[c] zipWith z (a:as) (b:bs) = z a b : zipWith z as bs zipWith _ _ _ = [] }}} At first I thought that this definition will imply `zipWith (+) [] ? = ?`, but that doesn?t seem to be the case ? pattern are tried from left to right. So while I dislike the slight asymmetry here, I don?t think it is justified to not follow the standard here. OTOH, I also don?t think that the semantic change, although a wart, is bad enough to justify not being able to fuse on one or the other side. I also think it is reasonable to try to fuse on boths sides (even if the result is not confluent if we could fuse on both sides). So I currently don?t see how to improve the code. Which leaves us improving the documentation. Would you provide a patch against that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 07:47:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 07:47:15 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.baf3738f1e6b2ba6f070d5ca399bf9d5@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 nomeata]: > So while I dislike the slight asymmetry here, I don?t think it is justified to not follow the standard here. We ''already'' aren't following the standard here! These are the three options I see (tl;dr: I think options 1 and 3 deserve serious consideration, and option 4 less; option 2 is more a Haskell Prime kind of question): 1. Eliminate `foldr1/right`, which will bring us into compliance with the standard, and change the documentation to indicate that we only fuse on the left list. The confluence problem is eliminated. The only downside is that if someone is relying on this rule, then their code will slow down. They will be able to fix this easily, but only if they pay attention to GHC release notes, are still maintaining their code, etc. 2. Change the baseline (not rewritten) definition of `foldr2` to check for nil on the second list first, and then eliminate `foldr1/left`. Document a violation of the standard. This also eliminates the confluence problem. I think it's arguably friendlier to fuse on the ''last'' argument than the first. That said, I don't think this is really a sensible option at this point because it has the downsides of most of the other options combined. 3. Change the baseline (not rewritten) definition of `foldr2` to force the second list to WHNF if the first is nil, rendering `foldr2` symmetrical. Document a violation of the standard. This approach ensures (I ''believe'') that the (still non-confluent) rules cannot produce bottoms that weren't there before. Personally, I would consider this the most conservative acceptable approach. 4. Leave things as they are in the code, but explain the situation in the documentation. I don't like this option, for the simple reason that code that runs correctly with `-O0` and doesn't do anything weird with funky `GHC.*.*` or `unsafe*` functions really should also run correctly with `-O`, but currently that is not the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 10:05:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 10:05:31 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.f1fbee81197d3f2f5b291eeb56a7679f@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Simon: Do you believe the document I wrote (https://www.fpcomplete.com /tutorial-preview/4431/z0KpB0ai2R) is in a good enough state to submit for wider review, perhaps on the GHC mailing list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 16:04:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 16:04:25 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.ad91a2828231dac6d21f08afc9051d7f@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > We already aren't following the standard here! hmm, true. In that case I?m in favor of 3. I don?t think we guarantee confluence anywhere, and I?m not sure if it is worth more than possibilities for fusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 17:24:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 17:24:41 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.db4a118eb5ad96eac1bb0fe847fd87b3@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | 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 alpmestan): * cc: alpmestan@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 18:56:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 18:56:37 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.5e01ffd386efa914b4d5766fa99595a5@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I just had a problem due to this on NixOS, what would be the way to push this ticket forward bar fixing it myself? I'm afraid that it will just keep getting the milestone bumped forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 18:57:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 18:57:28 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d889b11ae9fe6b73137eef880706f72b@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * cc: fuuzetsu@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 19:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 19:03:30 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.03344ec94cf40d2794b388c24047025d@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): I submitted a patch yesterday with which I managed to create byte- identical binaries with `ghc --make` (and `cabal build` if you use cabal 1.20): https://github.com/nh2/ghc/compare/deterministic-binaries https://phabricator.haskell.org/D175 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 24 19:59:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Aug 2014 19:59:09 -0000 Subject: [GHC] #9512: T9329 fails test on unregisterised i386 Message-ID: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> #9512: T9329 fails test on unregisterised i386 ----------------------------+------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: T9329 Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- ghc-HEAD '''./configure --enable-unregistersied''' on i386-linux fails as: {{{ =====> T9329(normal) 118 of 4091 [0, 0, 0] cd ./codeGen/should_compile && '/root/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-ghci-history -c T9329.cmm -no-hs-main >T9329.comp.stderr 2>&1 Compile failed (status 256) errors were: /tmp/ghc23160_0/ghc23160_2.hc: In function ?foo?: /tmp/ghc23160_0/ghc23160_2.hc:10:12: error: ?c0_info? undeclared (first use in this function) *Sp = (W_)&c0_info; ^ /tmp/ghc23160_0/ghc23160_2.hc:10:12: note: each undeclared identifier is reported only once for each function it appears in }}} The generated C code is: {{{ /* GHC_PACKAGES */ #include "Stg.h" FN_(foo) { FB_ _c0: if ((W_)(((W_)Sp-4) < (W_)SpLim)) goto _c2; else goto _c3; _c2: *Sp = (W_)&c0_info; JMP_((W_)&stg_gc_noregs); _c3: R1.w = 0x0; JMP_(*((P_)(*Sp))); FE_ } }}} while on UNREG x86_64 test does not fail and generates the following C: {{{ /* GHC_PACKAGES */ #include "Stg.h" FN_(foo) { FB_ _c0: goto _c3; _c3: R1.w = 0x0; JMP_(*((P_)(*Sp))); FE_ } }}} Looks like there is no stack check at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 07:21:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 07:21:26 -0000 Subject: [GHC] #9497: Silent typed holes In-Reply-To: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> References: <045.44f02f56e1d82f152039c59defbcbbe5@haskell.org> Message-ID: <060.00e157b74988eb0b559160fa26a11e8c@haskell.org> #9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: typed holes, Resolution: | warnings 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): OK I think we are more or less agreed here. Does someone feel like offering a patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 07:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 07:33:53 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.757bde229c6e74b4da9690f2e11de3a8@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Personally I like "package key". It's pretty clear that it's something you have to look up to find out what it means, and doesn't clash with other concepts in GHC/Cabal. (Eg "instance" has many meanings!) I could cope with "package instance". I don't much like "library ID". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 08:09:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 08:09:23 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.e27ca44dd45ea8efed7f11b95fb95052@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): To broaden this a bit, it is worth remembering that ''the main `foldr/build` rule itself is unsound in the presence of `seq`''. See, for example, the [http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#In_the_presence_of_seq Haskell wiki page]. This is not nice. The "right" solution is for `seq` to be an operation of a type class, something that was the case in Haskell originally, and then changed after ''extensive'' debate on the Haskell committee. So currently we are stuck in the unsatisfactory situation that certain optimisations, which have a generally very beneficial effect on performance, can change termination behaviour. Eta reduction/expansion is another. In that general context I don't have a strong opinion about the `foldr2` question. I'd consult the Core Libraries Committee. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 08:21:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 08:21:24 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.57c31fd35a9fb5165be42a165761f905@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for producing a patch. THAT is the best way to move the ticket forward! I've added a saying: The above patches look commendably small. But the resulting code contains absolutely no clue about the importance of the way those particular lines of code are written. Please, I beg, * write a Note [Deterministic builds] somewhere, * describe the issues in the note, * mention the ticket #4012 for more background * refer to the Note from the places in the code that are carefully written to support determinism See our [wiki:Commentary/CodingStyle Coding Style guidelines]. Thank you! Does that close the ticket? Or are there further determinism issues? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 09:08:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 09:08:12 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.8a4cb68ac1d670436152280594dec68b@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Basically yes. Some additional thoughts: * "...To quote the docs for pseq" This seems like a complete non-sequitur when talking about `seq`, and in any case only documents `seq` in a sideways kind of way. Better to quote the (brand new) documentation for `seq`. (Add a note to say it's new if you like.) * "...If we want to be certain of the ordering, use pseq". That's the place to quote pseq's documentation. * "You might think (as I did) that we can get the same guaranteed ordering of evaluation by having a function which is only strict in one of its arguments:" This is a bit confusing, because we don't know if `(+)` here is overloaded. I assume you mean `(+)` at `Int`? If so, it's strict in both arguments, so adding the strictness annotation doesn't change anything anyway. A `!` would only have a chance of changing evaluation order if the function was lazy. And if it was lazy then the `!` would make it strict, and that ''would'' be preserved by inlining. So maybe my earlier comment about inlining was a red herring. * I think it might be helpful to articulate the baseline story for `unsafePerformIO`, namely: use it only when you don't mind which order the effects are performed in, relative to both the main I/O monad and other calls to `unsafePerformIO`. You are on thin ice if you go beyond that; and the thin ice is what this tutorial discusses. * "to understand why unsafeInterleaveIO is semantically different from return . unsafePerformIO, we need to drop down a layer of abstraction". Not really. To understand ''how'', you need to drop down. But the guarantees are perfectly well defined. Given `do { ...before...; x <- unsafeInterleaveIO (...side...); ...after...}` then: * Effects in `...side...` will happen after effects in `...before...`. * But effects in `...side...` maybe occur arbitrarily interleaved with effects in `...after...`. * I am not sure what the `lazy` in `unsafeDupablePeformIO` is either! Maybe Simon Marlow does? I think it's good enough to launch on the masses though. Thanks for doing this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 09:58:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 09:58:21 -0000 Subject: [GHC] #9512: T9329 fails test on unregisterised i386 In-Reply-To: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> References: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> Message-ID: <060.3c88200ef2ca754497bf0b718992d5bc@haskell.org> #9512: T9329 fails test on unregisterised i386 -------------------------------------------+--------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9329 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by slyfox): To crash it on unreg amd64 it's enough to increase the value: {{{ foo () { - STK_CHK_GEN_N (8); /* panics */ + STK_CHK_GEN_N (16); /* panics */ return (0); } }}} {{{ /tmp/ghc28946_0/ghc28946_2.hc:10:12: error: ?c0_info? undeclared (first use in this function) *Sp = (W_)&c0_info; ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 10:05:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 10:05:05 -0000 Subject: [GHC] #9512: T9329 fails test on unregisterised i386 In-Reply-To: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> References: <045.e8f5ea5daa466f61185e5401527f83c6@haskell.org> Message-ID: <060.520495fca77d0b41435d6a0cb5930efc@haskell.org> #9512: T9329 fails test on unregisterised i386 -------------------------------------------+--------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: T9329 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+--------------------------- Comment (by Sergei Trofimovich ): In [changeset:"5295cd2b53cb2e9cf3df49274d25d3f72d618c2a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5295cd2b53cb2e9cf3df49274d25d3f72d618c2a" testsuite: add 16-byte case for T9329 Exposes Issue #9512 on amd64 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 10:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 10:18:18 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.05197a442c846e8ad769551b0502cc6e@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Thanks for the further review. I've made some updates based on these comments, and have published the document. I'll email Simon Marlow about `lazy` in `unsafeDupablePerformIO`, and send an email to the GHC mailing list about the document in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 12:32:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 12:32:46 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.5108f78b273f18277c1bf5b5c3a91bb0@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 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: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:6 simonpj]: > To broaden this a bit, it is worth remembering that ''the main `foldr/build` rule itself is unsound in the presence of `seq`''. See, for example, the [http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#In_the_presence_of_seq Haskell wiki page]. > > This is not nice. The "right" solution is for `seq` to be an operation of a type class, something that was the case in Haskell originally, and then changed after ''extensive'' debate on the Haskell committee. > > So currently we are stuck in the unsatisfactory situation that certain optimisations, which have a generally very beneficial effect on performance, can change termination behaviour. Eta reduction/expansion is another. > > In that general context I don't have a strong opinion about the `foldr2` question. I'd consult the Core Libraries Committee. > > Simon Without a doubt, these are not nice. But we generally keep the danger under control. We make the compiler prove that eta expansion is safe before applying it (I'm not sure what happens with eta reduction). We hide `build` away from the normal user libraries to allow us to pretend it will only be used by people who have read the necessary documentation (yes, that documentation may need some improvement). But `foldr2`, `zipWith`, and `zip` are completely exposed, right in the Prelude, along with a `filter` for them to crash with! David -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:00:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:00:16 -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.b5856c726263ba648a31dcd38ed1158b@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: | -------------------------------------+------------------------------------- Comment (by simonpj): Re-opening because of comment:9 and following. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:00:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:00:36 -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.249ae9a4975a76c8aeda3e4270f7f296@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | 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 simonpj): * owner: cactus => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:12:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:12:20 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.f45848db2804fcf64e70b05828a1ff1a@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 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 Simon Peyton Jones ): In [changeset:"af4bc31c50c873344a2426d4be842f92edf17019/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="af4bc31c50c873344a2426d4be842f92edf17019" Do not duplicate call information in SpecConstr (Trac #8852) This long-standing and egregious bug meant that call information was being gratuitously copied, leading to an exponential blowup in the number of calls to be examined when function definitions are deeply nested. That is what has been causing the blowup in SpecConstr's running time, not (as I had previously supposed) generating very large code. See Note [spec_usg includes rhs_usg] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:13:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:13:06 -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.98eab8cec463186727ddc3a85c39bdfa@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Hmm. Implementation-wise, there's no reason why `P`-as-an-expression and `P`-as-a-pattern has to have the same constraints -- in fact, they could even have completely different types... But we check that they do have the same type so that they behave more like a real constructor. The reason `CE := CP + CR` at the moment is that this is how a GADT constructor is typed. So, ummm, how far do we want to let pattern synonym types wander from regular constructor types? That is the question here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:13:46 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.95816a7cd9f3d3e400633f246b76029a@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: 8581 Type of failure: | None/Unknown | Test Case: | Blocking: 8968 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * related: => 8581 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:25:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:25:42 -0000 Subject: [GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc In-Reply-To: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> References: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> Message-ID: <060.a3eca7f5438f8ebbb902a12cffc8fb83@haskell.org> #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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): * status: new => infoneeded Comment: I believe this is fixed; see #8852. Can you try now, with HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:26:04 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.22e003a623c90667d592ab4e7c782a95@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => infoneeded Comment: I believe this is finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:26:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:26:19 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.0a687fa45cb964c582082feabd7f2ff3@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -------------------------------------+------------------------------------- Reporter: | Owner: MichalGajda | Status: new Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7068, #7898 time crash | Test Case: cabal | install hPDB | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe this is finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:26:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:26:45 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.db74761f691caef0d3bbd50f5dd8ceed@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe this is finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:27:28 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.c7a4796435ad4a3546c18c9bb4cf3826@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 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 simonpj): * status: new => infoneeded Comment: I believe this may be finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:27:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:27:49 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.81bf7afc716f23a00df297d57c3d3b9f@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: 5550 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * difficulty: => Unknown * resolution: duplicate => Comment: I believe this is finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:27:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:27:55 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.36a77138e09ffeeeb49002a65051e3ba@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: 5550 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:28:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:28:12 -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.186bf731531eaaf775b949a97d11acfa@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: ekmett => * status: closed => new * resolution: fixed => Comment: Reopening to set to `patch` state, so we don't lose this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:28:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:28: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.544b3463693d3b486a3b5bb134ba1b10@haskell.org> #4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:29:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:29:17 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.7ad72cd45bc3719748eba88e42cc4c35@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 -------------------------------------+------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: duplicate => Comment: I believe this is finally fixed; see #8852. Can you try now, with HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:29:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:29:22 -0000 Subject: [GHC] #8836: ghc 7.6.3 and 7.4.2 hang on -O2 In-Reply-To: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> References: <046.6df6863e3c6e5f69cd138b1da97403ae@haskell.org> Message-ID: <061.ee6f00bd17234b78c42090972e5a2fbe@haskell.org> #8836: ghc 7.6.3 and 7.4.2 hang on -O2 -------------------------------------+------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:31:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:31:03 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.75aa661113394c0fe4ce03f7d85692fa@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed Comment: OK I have finally fixed this bug. I think there is a good chance that doing so has also fixed #8852, #8980, #8941 (possibly), #8960, #7898, #7068, #7944, #8836. I have turned these tickets into info-needed status, because they are hard to reproduce, but this ticked #8852 is definitely fine now. It's kind of hard to make a regression test without depending on an (out of date version of) attoparsec, and its dependencies, so I'm not adding a regression test at all for now. Phew Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 13:32:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 13:32:01 -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.4062fadcd7009478ed7cd68a2c55a4e6@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Ideally, as far as the programer wants, provided CP is provable from CE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 14:18:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 14:18:25 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable In-Reply-To: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> References: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> Message-ID: <063.f531dd366b7b8a18cc96dbdae7267f4e@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (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:"8ff4671422090acf9146e3a90dd38e2c6f72aebb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8ff4671422090acf9146e3a90dd38e2c6f72aebb" Make Core Lint check for un-saturated type applications Un-saturated type-family and type-synonym applications are detected in the front end, but for some reason Lint wasn't looking for them. I came across this when wondering why Trac #9433 didn't give a Core Lint error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 14:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 14:18:26 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable In-Reply-To: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> References: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> Message-ID: <063.2444078b577c2b8c1b4d30cfd6805abd@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (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:"ee4501bbad6480509e8a60b5ff89c0b0b228b66d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ee4501bbad6480509e8a60b5ff89c0b0b228b66d" Check for un-saturated type family applications This patch corrects an egregious error introduced by: commit 022f8750edf6f413fba31293435dcc62600eab77 Author: Simon Peyton Jones Date: Thu May 15 16:07:04 2014 +0100 Refactoring around TyCon.isSynTyCon * Document isSynTyCon better * Add isTypeSyonymTyCon for regular H98 type synonyms * Use isTypeSynonymTyCon rather than isSynTyCon where the former is really intended At this particular spot in TcValidity we really do mean isSynTyCon and not isTypeSynonymTyCon. Fixes Trac #9433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 14:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 14:18:26 -0000 Subject: [GHC] #9436: Confusing error message with RecordWildCards In-Reply-To: <047.899387691d241ae17d7487e257f38c52@haskell.org> References: <047.899387691d241ae17d7487e257f38c52@haskell.org> Message-ID: <062.396bc8d142890e7fcf8a357c92d329fc@haskell.org> #9436: Confusing error message with RecordWildCards -------------------------------------+------------------------------------- Reporter: elliottt | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"06600e74444d22caff1fa8c7eef0e4e2debd60b9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="06600e74444d22caff1fa8c7eef0e4e2debd60b9" Two buglets in record wild-cards (Trac #9436 and #9437) of named fields, whereas the code in RnPat.rnHsRecFields is much better set up to do so. Both easily fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 14:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 14:18:26 -0000 Subject: [GHC] #9437: Wrong error message when using `..' with a record update In-Reply-To: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> References: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> Message-ID: <062.1a5b73f5f406d177c6fb4df4bed23e9d@haskell.org> #9437: Wrong error message when using `..' with a record update -------------------------------------+------------------------------------- Reporter: elliottt | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"06600e74444d22caff1fa8c7eef0e4e2debd60b9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="06600e74444d22caff1fa8c7eef0e4e2debd60b9" Two buglets in record wild-cards (Trac #9436 and #9437) of named fields, whereas the code in RnPat.rnHsRecFields is much better set up to do so. Both easily fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:05:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:05:08 -0000 Subject: [GHC] #9437: Wrong error message when using `..' with a record update In-Reply-To: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> References: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> Message-ID: <062.4c5c8350e21bf3eb0fe51d1dc4d321ae@haskell.org> #9437: Wrong error message when using `..' with a record update -------------------------------------+------------------------------------- Reporter: elliottt | 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: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks for reporting this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:05:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:05:39 -0000 Subject: [GHC] #9436: Confusing error message with RecordWildCards In-Reply-To: <047.899387691d241ae17d7487e257f38c52@haskell.org> References: <047.899387691d241ae17d7487e257f38c52@haskell.org> Message-ID: <062.672c67e1a8d7a83453d41b930669345e@haskell.org> #9436: Confusing error message with RecordWildCards -------------------------------------+------------------------------------- Reporter: elliottt | 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: | rename/should_fail/T9436 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T9436 Comment: Thanks for reporting this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:05:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:05:57 -0000 Subject: [GHC] #9437: Wrong error message when using `..' with a record update In-Reply-To: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> References: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> Message-ID: <062.bda0f9743b2223b728f33fef09af299c@haskell.org> #9437: Wrong error message when using `..' with a record update -------------------------------------+------------------------------------- Reporter: elliottt | 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: | Blocked By: None/Unknown | Related Tickets: Test Case: | rename/should_fail/T9437 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T9437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:07:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:07:05 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable In-Reply-To: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> References: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> Message-ID: <063.b25eeeaec43e91a06bb61c92bddf20c3@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 (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: indexed- | types/should_fail/T9433 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_fail/T9433 Comment: Thanks for reporting this. Austin: worth merging `ee4501` if we make 7.8.4 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:07:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:07:27 -0000 Subject: [GHC] #9436: Confusing error message with RecordWildCards In-Reply-To: <047.899387691d241ae17d7487e257f38c52@haskell.org> References: <047.899387691d241ae17d7487e257f38c52@haskell.org> Message-ID: <062.91a606a9d1db740e832ccf6ccfe5a9de@haskell.org> #9436: Confusing error message with RecordWildCards -------------------------------------+------------------------------------- Reporter: elliottt | 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: | Blocked By: None/Unknown | Related Tickets: Test Case: | rename/should_fail/T9436 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:18:18 -0000 Subject: [GHC] #9437: Wrong error message when using `..' with a record update In-Reply-To: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> References: <047.307821b7e101e6e4eecb0581bcd57bce@haskell.org> Message-ID: <062.a43fb7aa26e2268f09559663e20fcecd@haskell.org> #9437: Wrong error message when using `..' with a record update -------------------------------------+------------------------------------- Reporter: elliottt | 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: | Blocked By: None/Unknown | Related Tickets: Test Case: | rename/should_fail/T9437 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"67a6ade91b77fb2252ebdad34a934d9fb54eb43d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67a6ade91b77fb2252ebdad34a934d9fb54eb43d" Improve documentation of record wildcards In particular mention that they aren't allowed for record updates. Triggered by Trac #9437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:29:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:29:01 -0000 Subject: [GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc In-Reply-To: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> References: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> Message-ID: <060.d045ed8585c0a59589d9d3dba30673cb@haskell.org> #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 slyfox): * status: infoneeded => closed * resolution: => fixed Comment: Now all builds fine and does not crash ghc! Thanks! Some stats (both runs are '''-O2 -j4 --make'''): highlighting-kate alone now takes about ~3.7GBs RAM 'selfcontained-eater-ghc-7.8-rc2.tar.gz' now takes ~7.1GBs RAM and contains 452 modules Which is very sane for amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:39:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:39:46 -0000 Subject: [GHC] #9513: Building GHC on Windows Message-ID: <048.511f109539d5b05fe095941eac814f1c@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I am trying to build GHC 7.8.3 on my computer, but in final phase of building it fails. I have downloaded both packages with sources, one with compiler and minimal set of libraries, second with extra building tools required on Windows. I have unzipped files to same folder. I was following instructions given in your wiki. I installed required tools and set PATH variable. Next I run ./configure and it finished successfully, but when I have executed make, it has stopped with errors In a block below there is an output of make. {{{ ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all driver/ghci/ghc.mk:39: driver/ghci/dist/build/.depend.c_asm: No such file or directory rts/ghc.mk:515: rts/dist/build/.depend-v-p-l-debug-thr-thr_debug-thr_l- thr_p.c_asm: No such file or directory libraries/old-time/ghc.mk:5: libraries/old-time/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/old-time/ghc.mk:5: libraries/old-time/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/Win32/ghc.mk:4: libraries/Win32/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/Win32/ghc.mk:4: libraries/Win32/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist- install/build/.depend-v-p.haskell: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist- install/build/.depend-v-p.c_asm: No such file or directory libraries/integer-gmp/mkGmpDerivedConstants/ghc.mk:20: libraries/integer- gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm: No such file or directory utils/haddock/ghc.mk:15: utils/haddock/dist/build/.depend.haskell: No such file or directory utils/haddock/ghc.mk:15: utils/haddock/dist/build/.depend.c_asm: No such file or directory compiler/ghc.mk:640: compiler/stage2/build/.depend-v-p.haskell: No such file or directory make -C libffi/build MAKEFLAGS= install MAKE i686-pc-mingw32 : 0 * install make[3]: Entering directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32' Making install in include make[4]: Entering directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32/include' make[5]: Entering directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32/include' make[5]: Nothing to be done for `install-exec-am'. test -z "c:/ghc-7.8.3/libffi/build/inst/lib/libffi-3.0.11/include" || /c/MinGHC/msys/1.0/bin/mkdir -p "c:/ghc-7.8.3/libffi/build/inst/lib/libffi-3.0.11/include" ../install-sh -c -m 644 ffi.h ffitarget.h 'c:/ghc-7.8.3/libffi/build/inst/lib/libffi-3.0.11/include' /bin/sh: line 7: ../install-sh: No such file or directory make[5]: *** [install-nodist_includesHEADERS] Error 127 make[5]: Leaving directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32/include' make[4]: *** [install-am] Error 2 make[4]: Leaving directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32/include' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/c/ghc-7.8.3/libffi/build/i386-unknown- mingw32' make[2]: *** [install] Error 2 make[1]: *** [libffi/stamp.ffi.static.install] Error 2 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:54:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:54:11 -0000 Subject: [GHC] #7863: Verbosity level for quieter Template Haskell In-Reply-To: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> References: <044.036cc2d0e36ca0d39d050837fff3a1a3@haskell.org> Message-ID: <059.ba790026ba28a9c97967bb6030af3ffd@haskell.org> #7863: Verbosity level for quieter Template Haskell -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.6.3 Component: Template | Keywords: linker 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 hvr): * cc: hvr (added) * keywords: => linker * priority: normal => low * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 15:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 15:58:25 -0000 Subject: [GHC] #9444: -ddump-deriv doesn't dump failed newtype-deriving In-Reply-To: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> References: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> Message-ID: <062.422a45a994aa51778c757cfde54beb9d@haskell.org> #9444: -ddump-deriv doesn't dump failed newtype-deriving -------------------------------------+------------------------------------- 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): Think about {{{ data T = MkT Int Int Bool (Int -> Bool) deriving( Read ) }}} You probably ''don't'' want to see the parser code generated by a derived `Read` instance. What you want to know is that the derived instance needs `Read` on each constructor argument. {{{ T9444.hs:6:37: No instance for (Read (Int -> Bool)) arising from the first field of ?MkT? (type ?Int -> Int?) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Read T) }}} It's the same for deriving `C`. What you need to know is that we need a `Coercible (Int -> F Int) (Age -> F Age)` for each method of `C`. (Here there is just one.) And that is what fails: {{{ T9444.hs:16:12: Could not coerce from ?Bool? to ?F Age? because ?Bool? and ?F Age? are different types. arising from the coercion of the method ?meth? from type ?Int -> F Int? to type ?Age -> F Age? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (C Age) }}} I think it's a pretty good error message! I suppose the `arising from` part could say: {{{ arising from the derived definition of method 'meth': instance ... => C Age where meth = coerce meth }}} but I'm not sure that will be much better, would it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 17:58:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 17:58:00 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.67c42874e6dd94c6c12fd83302cde5fb@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 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ibotty): * cc: haskell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 20:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 20:22:07 -0000 Subject: [GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. In-Reply-To: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> References: <051.9deb02feaf66c13b5aa3da47e90da868@haskell.org> Message-ID: <066.1abb77a2a63b243a4c2330f6ee75f025@haskell.org> #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: implicit- Documentation | parameter instance-constraints Resolution: fixed | 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 dimitris): But it's a useful feature, although arguably a bit dangerous to use ... For instance I am working with a library that someone else has written that exposes only a type-class based interface, i.e. you provide instances of certain classes. Now these classes provide -- sadly -- only a functional interface, so the only way for me to parameterize my instance implementation is to use a class instance context. But if that context can't itself be an implicit parameter or its instances depend on an implicit parameter then it's pretty impossible to reconfigure my code! So I think there is a pretty compelling case to /omit/ that check and perhaps warn users that this may lead to unpredictable behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 21:54:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 21:54:15 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.a2f3d9cb9bf781d976618099672fc59a@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The `lazy` on `unsafeDupablePerformIO` comes from this commit: e23efcffb3ebca88826044e3a8b818924c42e7ae. Looks like it ought to be documented, if the reason is still valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 21:57:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 21:57:33 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.d079eba127b92f503f0603483ba78352@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh, I just noticed it *is* documented: https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/IO.hs#l190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 25 22:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Aug 2014 22:05:47 -0000 Subject: [GHC] #9514: Haddock panics when exporting a module with pattern synonyms Message-ID: <051.724e8731cbd989337a8289cb4a174715@haskell.org> #9514: Haddock panics when exporting a module with pattern synonyms -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: haddock | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- First of all: Haddock version: '''2.14.3''', GHC version: '''7.8.3'''. Create 2 files, `PatSymDef.hs` and `PatSymUse.hs`: {{{#!hs -- PatSymDef.hs {-# Language PatternSynonyms #-} module PatSymDef where pattern Pat = () }}} {{{#!hs -- PatSymUse.hs {-# Language PatternSynonyms #-} module PatSymUse (module PatSymDef) where import PatSymDef }}} Run Haddock on them: {{{ [yom at shiny tmp]$ haddock -h PatSymDef.hs PatSymUse.hs Haddock coverage: Warning: Not found in environment: PatSymDef.Pat 50% ( 1 / 2) in 'PatSymDef' haddock: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): mkUsage <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And with `-ddump-if-trace`: {{{ [yom at shiny tmp]$ haddock -h PatSymDef.hs PatSymUse.hs --optghc='-ddump-if- trace' Haddock coverage: Considering whether to load base:Prelude Reading interface for base:Prelude; reason: Prelude is directly imported readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Prelude.dyn_hi updating EPS_ updating EPS_ Considering whether to load base:GHC.Base {- SYSTEM -} Reading interface for base:GHC.Base; reason: Loading orphan modules (base:GHC.Base) readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Base.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Base.dyn_hi updating EPS_ Considering whether to load base:GHC.Float {- SYSTEM -} Reading interface for base:GHC.Float; reason: Loading orphan modules (base:GHC.Float) readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Float.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Float.dyn_hi updating EPS_ Considering whether to load base:GHC.Real {- SYSTEM -} Reading interface for base:GHC.Real; reason: Loading orphan modules (base:GHC.Real) readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Real.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/GHC/Real.dyn_hi updating EPS_ loadHiBootInterface main:PatSymDef Starting fork { Declaration for Monad Loading decl for GHC.Base.Monad updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} Reading interface for ghc-prim:GHC.Prim; reason: Need home interface for wired-in thing * updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} tc-iface-class1 Monad tc-iface-class2 Monad tc-iface-class3 Monad tc-iface-class4 Monad buildClass buildClass GHC.Base.Monad } ending fork Declaration for Monad Need decl for Control.Applicative.Applicative Considering whether to load base:Control.Applicative {- SYSTEM -} Reading interface for base:Control.Applicative; reason: Need decl for Control.Applicative.Applicative readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Control/Applicative.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Control/Applicative.dyn_hi updating EPS_ Starting fork { Declaration for Applicative Loading decl for Control.Applicative.Applicative updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} tc-iface-class1 Applicative tc-iface-class2 Applicative tc-iface-class3 Applicative tc-iface-class4 Applicative buildClass buildClass Control.Applicative.Applicative } ending fork Declaration for Applicative Need decl for Control.Monad.MonadPlus Considering whether to load base:Control.Monad {- SYSTEM -} Reading interface for base:Control.Monad; reason: Need decl for Control.Monad.MonadPlus readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Control/Monad.hi readIFace /usr/lib/ghc-7.8.3/base-4.7.0.1/Control/Monad.dyn_hi updating EPS_ Starting fork { Declaration for MonadPlus Loading decl for Control.Monad.MonadPlus updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} tc-iface-class1 MonadPlus tc-iface-class2 MonadPlus tc-iface-class3 MonadPlus tc-iface-class4 MonadPlus buildClass buildClass Control.Monad.MonadPlus } ending fork Declaration for MonadPlus Starting fork { Declaration for Alternative Loading decl for Control.Applicative.Alternative updating EPS_ Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -} tc-iface-class1 Alternative tc-iface-class2 Alternative tc-iface-class3 Alternative tc-iface-class4 Alternative buildClass buildClass Control.Applicative.Alternative } ending fork Declaration for Alternative ==================== Interface statistics ==================== Renamer stats: 7 interfaces read 4 type/class/variable imported, out of 1234 read 0 instance decls imported, out of 97 read 0 rule decls imported, out of 53 read Need decl for PatSymDef.Pat Considering whether to load main:PatSymDef {- SYSTEM -} Warning: Not found in environment: PatSymDef.Pat 50% ( 1 / 2) in 'PatSymDef' Considering whether to load base:Prelude Considering whether to load main:PatSymDef updating EPS_ Considering whether to load base:GHC.Base {- SYSTEM -} Considering whether to load base:GHC.Float {- SYSTEM -} Considering whether to load base:GHC.Real {- SYSTEM -} loadHiBootInterface main:PatSymUse haddock: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): mkUsage <
> 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 Tue Aug 26 00:25:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 00:25:28 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.044c8a739905fdccd6fe08c898639661@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 Artyom.Kazak): * cc: yom@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 05:07:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 05:07:09 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.1382e20cc4c083198f2db8c97a81aeb1@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | 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 archblob): I have attached a fix based on HEAD. The fix has no test case because I'm not sure what libraries are guaranteed to be present on every system so that the test won't fail. If you can think of any, let me know and I'll add a test case or someone else can do it. I'm sorry this took a week to rebase :-P. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 05:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 05:48:36 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll Message-ID: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- The problem is that it uses the same syntax as -XScopedTypeVariables to mean something a bit different, and incompatible. -XExplicitForAll is of rather limited utility, whereas -XScopedTypeVariables is a wonderful thing. Confusion is bad. {{{#!hs f :: forall a . a -> [a] f a = let g :: a -> a g x = x in g [a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 07:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 07:40:34 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.2f113a1676dd391ab45ebbde3646891d@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by schyler): Did you `perl boot` and `./sync-all get` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 07:43:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 07:43:38 -0000 Subject: [GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples In-Reply-To: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> References: <047.7a3c851b84542a4fc8fa2798a8157164@haskell.org> Message-ID: <062.b58a1d34156d97b47384db9be947c656@haskell.org> #9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes thanks! '''First point'''. I really don't like the reasoning though. How would you explain to a client of `unsafePerformIO` what the specification is? Perhaps "the effects of the `unsafePerformIO` are all performed before the result is evaluated". But that is not true if the effects somehow depend strictly on the value concerned. If it's hard to specify, we should be cautious about relying on it. After all, the example {{{ unsafeDupablePerformIO (\s -> let r = f x in case writeIORef v r s of (# s1, _ #) -> (# s1, r #) ) }}} really '''is''' strict in `r`. If you evaluate it, since `writeIORef` returns `r`, it's clear that `r` will be evaluated. Saying "I want to write the reference before evaluating `r` is very delicate!". Moreover you can achieve the same effect, where it matters, with less magic. Here is the current code from `libraries/base/tests/Memo2.lhs`: {{{ memo' f ref weak_ref = \k -> unsafePerformIO $ do { ...blah... ; case lkp of Just res -> do { putMVar ref (size,table); return res } Nothing -> do { let res = f k ; ...blah... ; return res } }}} Now if we make the argument function given to `unsafePerformIO` return a 1-tuple thus, we are good: {{{ memo' f ref weak_ref = \k -> case do_effects k of {# result #) -> result where do_effects k = unsafePerformIO $ do { ...blah... ; case lkp of Just res -> do { putMVar ref (size,table); return (# res #) } Nothing -> do { let res = f k ; ...blah... ; return {# res #) } }}} Mind you (thinking aloud here), I suppose that this does rely on the strictness analyser not being super-clever. If `unsafePerformIO`'s signature was clever enough to say "in demand d, I call my function argument and evaluate the second component the result with demand d" then we'd be back in the same boat as before. Another, perhaps more robust alternative, would be to say: {{{ memo' f ref weak_ref = \k -> unsafePerformIO $ do { ...blah... ; case lkp of Just res -> do { putMVar ref (size,table); return res } Nothing -> do { let res = f k ; ...blah... ; return (lazy res) } }}} Here the `lazy` means that the `res` binding is not strict. Anyway the point it that this subtle stuff should be visible in the caller, for the rare moments when it is needed, rather than hidden in `unsafePerformIO`. All that said, there is is, and I suppose it may break things in rather subtle ways if we remove it. So perhaps we should leave specifically leave it un-documented! '''Second point'''. I think it would be clearer as {{{ unsafeDupablePerformIO (IO m) = case m realWorld# of (# _, r #) -> lazy r }}} That is, make the laziness wrap the 'r' part only, which is the important bit here. I tried this: {{{ {-# NOINLINE u1 #-} u1 :: IO a -> a u1 (IO m) = lazy (case m realWorld# of (# _, r #) -> r) {-# NOINLINE u2 #-} u2 :: IO a -> a u2 (IO m) = case m realWorld# of (# _, r #) -> lazy r {-# NOINLINE u3 #-} u3 :: IO a -> a u3 (IO m) = case m realWorld# of (# _, r #) -> r }}} and got this in the interface file: {{{ u1 :: GHC.Types.IO a -> a {- Arity: 1, HasNoCafRefs, Strictness: , Inline: NOINLINE -} c9e24d21e66094c44ef0629d326e9a33 u2 :: GHC.Types.IO a -> a {- Arity: 1, HasNoCafRefs, Strictness: , Inline: NOINLINE -} 83ded03238c0647421262c926910e195 u3 :: GHC.Types.IO a -> a {- Arity: 1, HasNoCafRefs, Strictness: , Inline: NOINLINE -} }}} The strictness signatures say this: * `u1` (the status quo) is lazy in its first argument (a function) * `u2` (which I advocate) calls the function and evaluates the result to HNF * `u3` (the buggy version with no `lazy`) calls the function and evaluates the second component of the pair it returns. So `u2` looks fine. I might try making that change and seeing if there are any regressions. Unless you can think of any reason not to. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 09:45:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 09:45:30 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.a373af9ddce059b2bfcc2ded34b61448@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by srutownik): Thank you for the quick reply. When I tried to build GHC yesterday I omitted executing {{{ perl boot}}}, because I am using source package distribution (obtained by your downloads page), the sources are not from git. In wiki it was mentioned that {{{ perl boot}}} is unnecessary in this case. However I have done everything from the beginning to make sure that I have not missed any step. I have created two separate dirs containing unzipped packages. Next I have executed {{{perl boot}}} in one of then. What is following I have executed {{{./configure}}} and {{{make}}} in both directories, but in both cases I have encountered the same errors as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 10:58:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 10:58:26 -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.f3d2a57534f8af3bbf06aebdaeb76763@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Question for mpickering. How would it be if the pattern synonym had just ONE type, but it was the most constraining of the two directions. Thus in your example, {{{ pattern type Add a a :: (View a, Construct a) => a }}} rather than {{{ pattern type Add a a :: (View a) => a }}} which is what we get from the pattern side, but which doesn't work on the expression side. The down-side is that pattern-matching would need a `(Construct a)` constraint that is not strictly necessary. How bad would that be? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 11:43:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 11:43:25 -0000 Subject: [GHC] #9514: Haddock panics when exporting a module with pattern synonyms In-Reply-To: <051.724e8731cbd989337a8289cb4a174715@haskell.org> References: <051.724e8731cbd989337a8289cb4a174715@haskell.org> Message-ID: <066.e3d4d684513f807c097bcc90e44cf9e5@haskell.org> #9514: Haddock panics when exporting a module with pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: cactus Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: haddock 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 11:46:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 11:46:29 -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.32053d32c20e94875f35d0dbc26a8b44@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms Resolution: | 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): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 11:46:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 11:46:46 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.7f656b565f49753828a3080ef5dc198c@haskell.org> #5144: Pattern synonyms -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 8581, | 8582, 8583, 8584 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 11:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 11:46:58 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.81df003559e2b37783b8f34261329205@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 cactus): * keywords: => pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 11:47:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 11:47:09 -0000 Subject: [GHC] #9514: Haddock panics when exporting a module with pattern synonyms In-Reply-To: <051.724e8731cbd989337a8289cb4a174715@haskell.org> References: <051.724e8731cbd989337a8289cb4a174715@haskell.org> Message-ID: <066.304f754dc11ca2286eb6e028a3fd1df3@haskell.org> #9514: Haddock panics when exporting a module with pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: cactus Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: haddock, pattern Resolution: | synonyms Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * keywords: haddock => haddock, pattern synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 14:35:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 14:35:55 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.6518fe3ca8d8f804b689686dde12f236@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by srutownik): I have tried to build GHC with sources cloned from git. I have also redirected output to files, so you can see whole output. steps: - {{{git clone -b ghc-7.8.3-release --recursive git://git.haskell.org/ghc.git ghc-7.8.3}}} - {{{cd ghc-7.8.3}}} - {{{git clone git://git.haskell.org/ghc-tarballs.git}}} - {{{sync-all get}}} - {{{perl boot}}} - {{{./configure}}} - {{{make}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 14:55:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 14:55:20 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.a644383d130c85f06a70c4e098b0d8f6@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): {{{ checking for a BSD-compatible install... ../install-sh -c }}} This appears to be the problem. The `install-sh` detected by configure needs to be an absolute path so that it can be invoked by sub-Makefiles. Do you have `..` in your PATH? Looks like that could cause this. (Though I am just judging from what happens on Linux; I have no familiarity with Windows.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 15:34:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 15:34:24 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.a16d1e535144c38706b1c5ae9afeab34@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by srutownik): During installation I am using msys Before all steps mentioned above I have set path as below {{{ export PATH=/c/ghc-7.8.3/inplace/mingw/bin:/c/Python27:/c/MinGHC/bin:/c/MinGHC/msys/1.0/bin:"/C/Program Files (x86)/Git/bin":/c/dev/llvm/bin:/e/2014.2.0.0-32/bin:/e/2014.2.0.0-32/lib/extralibs/bin:/e/VCMI/libs/x86 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 16:29:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 16:29:06 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.0e93a9bb8120bdb96dd9f91bea35c37d@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): OK, I read farther in configure and I see where `../install-sh` is coming from now. I can see how that ''could'' work but for some reason it doesn't actually appear to be working. How does your `libffi/build/i386-unknown-mingw32/include/Makefile` define `INSTALL`? (e.g. mine is `INSTALL = /usr/bin/install -c`.) It should be `../../install-sh -c`, but I expect it will actually be `../install-sh -c`. I would suggest as a workaround ensuring that you have an `install` on your path somewhere. Or someone familiar with Windows and autoconf should comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 17:11:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 17:11:35 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.8ac9ee50f9bac46547db21f327e8b245@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: | -------------------------------------+------------------------------------- Comment (by GregWeber): I am willing to help test this out. Need it for the persistent library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 18:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 18:28:58 -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.894351482519939400aafcc4845f7064@haskell.org> #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM -------------------------------------+------------------------------------- Reporter: vsajip | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Keywords: BOM Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: #1744 rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D176 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D176 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 19:46:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 19:46:18 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.6ab39854f5de0063256a76ee856d47ee@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Adding the source file and line number is also quite useful. So shouldn't the definition proposed by @simonpj include them? Or is there a specific reason not to? In fact, shouldn't the exception thrown by {{{undefined}}} include the file & lineno so that the added definition would then become simply {{{f = undefined}}}, as requested in the original ticket? I have already been at a loss by an error such as {{{*** Exception: Prelude.undefined}}} without any references to where. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 19:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 19:54:49 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.f073de73eda11735018f73173695e126@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: admin@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 26 23:19:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Aug 2014 23:19:14 -0000 Subject: [GHC] #2207: Load the interface details for GHC.* even without -O In-Reply-To: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> References: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> Message-ID: <061.1064589098d0c101c6dc866864508784@haskell.org> #2207: Load the interface details for GHC.* even without -O -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: 6.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 rodlogic): For what is worth, this is in 7.8.3: {{{ ??? ghc -ddump-simpl a.hs [1 of 1] Compiling Main ( a.hs, a.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 13, types: 7, coercions: 0} Main.main :: GHC.Types.IO () [GblId, Str=DmdType] Main.main = System.IO.putStrLn (GHC.Show.show @ GHC.Types.Bool GHC.Show.$fShowBool (GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt (GHC.Types.I# 1) (GHC.Types.I# 2))) :Main.main :: GHC.Types.IO () [GblId, Str=DmdType] :Main.main = GHC.TopHandler.runMainIO @ () Main.main }}} For: {{{ main = putStrLn $ show foo foo = (1 :: Int) == (2 :: Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 02:01:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 02:01:21 -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.fab6e52239f3487a9988a3f9e05db8e5@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: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Found [http://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf this] in section 11. {{{ 11 Syntax Extensions IDRIS supports the implementation of Embedded Domain Specific Languages (EDSLs) in several ways [4]. One way, as we have already seen, is through extending do notation. Another important way is to allow extension of the core syntax. In this section we describe two ways of extending the syntax: syntax rules and dsl notation. 11.1 syntax rules We have seen if...then...else expressions, but these are not built in. Instead, we can define a function in the prelude as follows (we have already seen this function in Section 3.7: boolCase : (x:Bool) -> Lazy a -> Lazy a -> a; boolCase True t e = t; boolCase False t e = e; and then extend the core syntax with a syntax declaration: syntax "if" [test] "then" [t] "else" [e] = boolCase test t e; The left hand side of a syntax declaration describes the syntax rule, and the right hand side describes its expansion. The syntax rule itself consists of: ? Keywords ? here, if, then and else, which must be valid identifiers ? Non-terminals ? included in square brackets, [test], [t] and [e] here, which stand for arbitrary expressions. To avoid parsing ambiguities, these expressions cannot use syntax extensions at the top level (though they can be used in parentheses). ? Names ? included in braces, which stand for names which may be bound on the right hand side. ? Symbols ? included in quotations marks, e.g. ":=". This can also be used to include reserved words in syntax rules, such as "let" or "in". The limitations on the form of a syntax rule are that it must include at least one symbol or keyword, and there must be no repeated variables standing for non-terminals. Any expression can be used, but if there are two non-terminals in a row in a rule, only simple expressions may be used (that is, variables, constants, or bracketed expressions). Rules can use previously defined rules, but may not be recursive. The following syntax extensions would therefore be valid: syntax [var] ":=" [val] = Assign var val; syntax [test] "?" [t] ":" [e] =iftestthentelsee; syntax "select" [x] "from" [t] "where" [w] = SelectWhere x t w; syntax "select" [x] "from" [t] = Select x t; Syntax macros can be further restricted to apply only in patterns (i.e., only on the left hand side of a pattern match clause) or only in terms (i.e. everywhere but the left hand side of a pattern match clause) by being marked as pattern or term syntax rules. For example, we might define an interval as follows, with a static check that the lower bound is below the upper bound using so: data Interval : Type where MkInterval : (lower : Float) -> (upper : Float) -> so (lower < upper) -> Interval We can define a syntax which, in patterns, always matches oh for the proof argument, and in terms requires a proof term to be provided: 44 pattern syntax "[" [x] "..." [y] "]" = MkInterval x y oh term syntax "[" [x] "..." [y] "]" = MkInterval x y ?bounds_lemma In terms, the syntax [x...y] will generate a proof obligation bounds_lemma (possibly renamed). Finally, syntax rules may be used to introduce alternative binding forms. For example, a for loop binds a variable on each iteration: syntax "for" {x} "in" [xs] ":" [body] = forLoop xs (\x => body) main : IO () main = do for x in [1..10]: putStrLn ("Number " ++ show x) putStrLn "Done!" Note that we have used the {x} form to state that x represents a bound variable, substituted on the right hand side. We have also put "in" in quotation marks since it is already a reserved word. 11.2 dsl notation The well-typed interpreter in Section 6 is a simple example of a common programming pattern with dependent types. Namely: describe an object language and its type system with dependent types to guarantee that only well-typed programs can be represented, then program using that representation. Using this approach we can, for example, write programs for serialising binary data [1] or running concurrent processes safely [2]. Unfortunately, the form of object language programs makes it rather hard to program this way in practice. Recall the factorial program in Expr for example: fact : Expr G (TyFun TyInt TyInt) fact = Lam (If (Op (==) (Var stop) (Val 0)) (Val 1) (Op (*) (app fact (Op (-) (Var stop) (Val 1))) (Var stop))) Since this is a particularly useful pattern, IDRIS provides syntax overloading [4] to make it easier to program in such object languages: dsl expr lambda = Lam variable = Var index_first = stop index_next = pop A dsl block describes how each syntactic construct is represented in an object language. Here, in the expr language, any IDRIS lambda is translated to a Lam constructor; any variable is translated to the Var constructor, using pop and stop to construct the de Bruijn index (i.e., to count how many bindings since the variable itself was bound). It is also possible to overload let in this way. We can now write fact as follows: fact : Expr G (TyFun TyInt TyInt) fact = expr (\x => If (Op (==) x (Val 0)) (Val 1) (Op (*) (app fact (Op (-) x (Val 1))) x)) In this new version, expr declares that the next expression will be overloaded. We can take this further, using idiom brackets, by declaring: (<$>) : |(f : Expr G (TyFun a t)) -> Expr G a -> Expr G t (<$>) = \f, a => App f a pure : Expr G a -> Expr G a pure = id 45 Note that there is no need for these to be part of an instance of Applicative, since idiom bracket notation translates directly to the names <$> and pure, and ad-hoc type-directed overloading is allowed. We can now say: fact : Expr G (TyFun TyInt TyInt) fact = expr (\x => If (Op (==) x (Val 0)) (Val 1) (Op (*) [| fact (Op (-) x (Val 1)) |] x)) With some more ad-hoc overloading and type class instances, and a new syntax rule, we can even go as far as: syntax "IF" [x] "THEN" [t] "ELSE" [e] = If x t e fact : Expr G (TyFun TyInt TyInt) fact = expr (\x => IF x == 0 THEN 1 ELSE [| fact (x - 1) |] * x) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 02:59:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 02:59:32 -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.4aea455621b6b2061fe24098cc1ced11@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: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @rodlogic I dont think deep embedding lambdas has ANYthing to do with the syntax extension support at alll :) Additionally, Idris needs because the default evaluation strategy is Strict anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 07:50:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 07:50:33 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.d9ba77579e302a7da9d6b0eaa516c674@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Comment (by kmels): Could you refer to the changeset where -fext-core was removed please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 07:51:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 07:51:14 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.709892c624fb4f24c3e9e688e34c4ad7@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 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: | -------------------------------------+------------------------------------- Changes (by kmels): * cc: c.lopez@? (added) * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 08:41:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 08:41:31 -0000 Subject: [GHC] #9513: Building GHC on Windows In-Reply-To: <048.511f109539d5b05fe095941eac814f1c@haskell.org> References: <048.511f109539d5b05fe095941eac814f1c@haskell.org> Message-ID: <063.95eab2a22d575c5f65aa04bca7d4f38d@haskell.org> #9513: Building GHC on Windows -------------------------------------+------------------------------------- Reporter: srutownik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by srutownik): Files {{{Makefile}}} in both, package and repository distribution, contains two definitions with {{{install-sh}}} string: {{{INSTALL = ../../install-sh -c}}} and {{{install_sh = ${SHELL} /c/new-1inst/ghc-7.8.3/libffi/build/install-sh}}} ({{{SHELL = /bin/sh}}}) {{{/c/new-1inst/ghc-7.8.3}}} is a root root directory for my ghc installation. install-sh file exists in specified path Thank you for your help. I would gladly accept any other suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 09:14:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 09:14:53 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.0114a79b385024333643e379cf4b7f6b@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Good idea. So far as I can see the '''sole''' effect of `-XExplicitForAll` is to enable the `forall` keyword. It's implied by `RankNTypes`, `ScopedTypeVariables`, `LiberalTypeSynonyms`, `ExistentialQuantification`. I'm all for deprecating it as a flag in its own right. Does anyone want to offer a patch? Need to update the user manual too, and get rid of uses of it in the GHC tree itself. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 09:35:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 09:35:33 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.aad97608d2097a5c8acce55e4fa3cd65@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by kosmikus): If the idea is to avoid confusion, and the `ExplicitForall` flag is currently implied by others, then shouldn't `RankNTypes`, `LiberalTypeSynonyms`, and `ExistentialQuantification` all imply `ScopedTypeVariables` instead? But that's somewhat non-obvious ... I personally think that while the current situation is unfortunate, the proposed solution isn't ideal either. I'd keep everything as it currently is, until we get to a point where we can agree that `ScopedTypeVariables` should be enabled by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 09:50:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 09:50:10 -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.855af9736d706412f22add4ad1ebf603@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 5144 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mpickering): It does feel unnecessary to insist on the extra constraint. That being said, it does match up better with the original semantics of the constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 10:54:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 10:54:46 -0000 Subject: [GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask Message-ID: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> #9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------+------------------------------------- Control.Exception exports {{{#!hs allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () }}} with documentation: ''When invoked inside `mask`, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation, but does not involve any actual blocking. When called outside `mask`, or inside `uninterruptibleMask`, this function has no effect.'' However, this is not actually true: `unsafeUnmask` unmasks exceptions even inside `uninterruptibleUnmask`, as the attached test demonstrates (the test uses a foreign call just to have something non-interruptible but still observable; in particular, doing a `print` ''is'' interruptible because it uses an `MVar` under the hood). I think it is possible to define a better `unsafeUnmask` in user-land: {{{#!hs interruptible :: IO a -> IO a interruptible act = do st <- getMaskingState case st of Unmasked -> act MaskedInterruptible -> unsafeUnmask act MaskedUninterruptible -> act }}} but it still seems to be that we should either (i) change the behaviour of unsafeUnmask, or (ii) provide a version of `unsafeUnmask` with the behaviour as described and then change `allowInterrupt` to use that new version of `unsafeUnmask`, or at the very least (iii) change the documentation. (One question with the above definition of `interruptible` is what happens when we ''nest'' `mask` and `uninterruptibleMask`?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 11:11:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 11:11:31 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.6405d37fdf1fe8b26c5c7ff3ce37303a@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by maeder): * cc: maeder@? (removed) Comment: Wow, I've created this ticket 9 years ago and I got used to live without this feature, although it should be simple to implement. (I hope my old username c_maeder was deleted.) To answer your question. Yes, source file and line number should be included (indicated by "or whatever") Adding source file and line number to the Exception for `undefined` is obviously not so easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 11:20:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 11:20:28 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.6c06a735fd1ad994f0d2ef6d97bfcf2c@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by maeder): also see #9049 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 14:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 14:50:21 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.5aa851c683007cb2c93fa3c81b200254@haskell.org> #5630: External Core needs love -------------------------------------+------------------------------------- Reporter: quux | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => wontfix Comment: Sure, please see commit 5bf22f06ef71f61094de7564dee770f136d5481a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 15:50:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 15:50:29 -0000 Subject: [GHC] #9517: hp2ps generates invalid postscript file Message-ID: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> #9517: hp2ps generates invalid postscript file -----------------------------+---------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+---------------------------------- Some of the outputs have a name such as foo(...). However, the postscript generation does not add an extra closing parenthesis after the foo(...). Example from attachment on line 410. ((447)modifyEdge.newEdges.(...) show This should presumably be: ((447)modifyEdge.newEdges.\(...\)) show Output from ps2pdf: Error: /syntaxerror in -file- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1163/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 40721 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 15:52:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 15:52:58 -0000 Subject: [GHC] #9515: Deprecate -XExplicitForAll In-Reply-To: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> References: <045.cc103ed5d657ec5c0590a52ea653d620@haskell.org> Message-ID: <060.34f5efe7d9e58d4b0e11b14690a822bf@haskell.org> #9515: Deprecate -XExplicitForAll -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 kosmikus]: > If the idea is to avoid confusion, and the `ExplicitForall` flag is currently implied by others, then shouldn't `RankNTypes`, `LiberalTypeSynonyms`, and `ExistentialQuantification` all imply `ScopedTypeVariables` instead? But that's somewhat non-obvious ... > > I personally think that while the current situation is unfortunate, the proposed solution isn't ideal either. I'd keep everything as it currently is, until we get to a point where we can agree that `ScopedTypeVariables` should be enabled by default. I think it would be great if `ScopedTypeVariables` (or conceivably something even better) were eventually implied by others, or even if it came to be the default behavior in the next Report. I think the first step in any case has to be phasing out the formally useless `ExplicitForAll`; once it's sufficiently dead, that syntactic space will be entirely free for a more useful replacement. You were wise to note the problem that `ExplicitForAll` is currently implied by other flags; I think the interim solution is to add a warning when those flags are used ''without'' `ScopedTypeVariables`: "`XxxxXxxxxx` currently implies `ExplicitForAll`, which is deprecated. To avoid this warning, add `ScopedTypeVariables` and rename type variables as necessary." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 16:02:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 16:02:23 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.0d497ac1590daa92dc312c63ad6db544@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: | -------------------------------------+------------------------------------- Comment (by duncan): See https://phabricator.haskell.org/D172 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 16:07:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 16:07:30 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.2076eb74a9e1812274945a55756bdb64@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dcoutts Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => dcoutts * differential: => D172 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 19:24:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 19:24:58 -0000 Subject: [GHC] #8857: Sparc needs to be on the NoSharedLibsPlatformList In-Reply-To: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> References: <046.258abaf74ed428bef525e7078c75e6a0@haskell.org> Message-ID: <061.766b481df59b1d271a02f5530fdc9784@haskell.org> #8857: Sparc needs to be on the NoSharedLibsPlatformList -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: sparc Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"78863edbb0751f5c9694ea10c6132a87cfd0ee10/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="78863edbb0751f5c9694ea10c6132a87cfd0ee10" Revert "disable shared libs on sparc (linux/solaris) (fixes #8857)" This reverts commit 623883f1ed0ee11cc925c4590fb09565403fd231. The commit a93ab43ab5f40cadbedea2f6342b93c245e91434 driver: pass '-fPIC' option to assembler as well fixes shared libraries on sparc at least on linux. Properly fixes Issue #8857 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 19:29:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 19:29:24 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.971c5cc5b47655eb53ded6978597cb6a@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by slyfox): The bug looks very much like SPARC's bug #8857 where compiler emitted one level more indirection, but assembler didn't generate proper relocations for it: https://phabricator.haskell.org/D177 I wonder if it cures ppc32 for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 19:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 19:48:25 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.f68d05a705724aefb0383879ed804429@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------ Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by jrp): Today's results: {{{ Unexpected results from: TEST="T367_letnoescape conc012 T5435_dyn_asm T5321FD T5030 T4801 T6048 T5631 T783 T5642 T9020 T3064 parsing001 T1969 T5321Fun T5837 T3294 cabal06 enum01 topHandler03 enum03 enum02" OVERALL SUMMARY for test run started at Wed Aug 27 19:57:51 2014 BST 0:34:19 spent to go through 4094 total tests, which gave rise to 16045 test cases, of which 3420 were skipped 315 had missing libraries 12114 expected passes 150 expected failures 3 caused framework failures 0 unexpected passes 43 unexpected failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/cabal06 cabal06 [bad stdout] (normal) concurrent/should_run T367_letnoescape [bad exit code] (optllvm) concurrent/should_run conc012 [bad exit code] (ghci) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler parsing001 [stat not good enough] (normal) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 19:51:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 19:51:15 -0000 Subject: [GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask In-Reply-To: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> References: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> Message-ID: <059.9bfa7cedcd28014b93a02ab1ff3324f0@haskell.org> #9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by simonmar): good catch, and a nice bug report. I think `unsafeUnmask` is fine, but the implementation of `allowInterrupt` is wrong, and we should replace it with your version. Would you like to submit a patch? (I'm on holiday right now, but no need to wait for me to approve it, Austin can approve and push.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 20:34:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 20:34:12 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.90c1c5209d347eaa847a0a740399c33a@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 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: | https://phabricator.haskell.org/D130| -------------------------------------+------------------------------------- Comment (by rodlogic): @ezyang: a slight bike-shedding ... what about {{{.hsi}}} or {{{.ihs}}} instead of {{{.hsig}}}? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 20:39:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 20:39:06 -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.439764f20abfbaeb67c91a54d1cbc0cf@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: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): @carter: ok, I did my best considering that the ticket assumes you understand what deep lambda embedding means in general and what your proposal means specifically. It would be good to elaborate a bit more what you are looking for here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 20:49:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 20:49:41 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.8c366b80bb2affc1ebd4be285436fecc@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: None | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually using this {{{ f :: Int -> Int f = _ -- Note "_" not "undefined" }}} plus compiling with `-fdefer-type-errors`, will give a runtime error when (and only when) `f` is called, giving file and line number. See [http://www.haskell.org/ghc/docs/latest/html/users_guide/typed-holes.html the manual on typed holes]. See #9497 for making this a bit better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 21:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 21:20:03 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.6a41620aedacb0e2b838c342db2ea35a@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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 simonpj): * owner: => goldfire Comment: I'm OK with `Ptr` being different. But if I have a `UArray (Int,Int) Age`, surely it's OK to cast it to `UArray (Int,Int) Int`, where {{{ newtype Age = MkAge Int }}} After all, `Int` and `Age` are represented identically, and it might be useful to make such a bulk conversion. Yes there might be different instances somewhere, but that's true of ''all'' uses of `coerce`. So I vote for the element parameter of these arrays being representational, rather than nominal. Unless someone has other arguments to make. Richard (or Joachim), might you do this, in due course? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 21:39:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 21:39:13 -0000 Subject: [GHC] #9260: Unnecessary error using GHC.TypeLits In-Reply-To: <051.9b98f43647329b740144a23edc96d4be@haskell.org> References: <051.9b98f43647329b740144a23edc96d4be@haskell.org> Message-ID: <066.5da6f72ad0fe8129e10daf368603a1f3@haskell.org> #9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: | Owner: diatchki Iceland_jack | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.2 Component: Compiler | Keywords: type lits, data Resolution: | kinds, error message Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki Comment: Iavor, might you look at this, as Mr type-lits? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 27 23:39:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Aug 2014 23:39:51 -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.e1cf9e69f15efa54d6602cb0cc7ad147@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: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @rodlogic, this ticket isn't meant to be a tutorial :) "make it easier to write Deep Embeddings with lambdas" is the meat of the ticket, the "DSL notation" section of the idris tutorial explains this with examples http://eb.host.cs.st-andrews.ac.uk/writings/idris-tutorial.pdf, which you can read in the preceding link -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 02:14:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 02:14:32 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations Message-ID: <047.7d86d581088086ed2263f989759fcf30@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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: -------------------------------------+------------------------------------- It would be nice if this message: {{{ Role mismatch on variable a: Annotation says representational but role nominal is required while checking a role annotation for `Point' }}} Could be extended to say where the requirement arises. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 04:19:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 04:19:22 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.35ea8e496ba6561ba6d45510a7ef1b3f@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dcoutts Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by duncan): See CabalDependency -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 05:39:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 05:39:11 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.299e7470a5e8e188e01c9286b85f278e@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dcoutts Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by refold): Very cool! Since these patches don't completely remove the dependency on Cabal from GHC, will it be at least possible to allow upgrading to new major Cabal versions in GHC point releases? It was annoying that the last few Haskell Platform releases had to ship with an old version of cabal- install because the Cabal version was fixed by GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 08:21:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 08:21:07 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations In-Reply-To: <047.7d86d581088086ed2263f989759fcf30@haskell.org> References: <047.7d86d581088086ed2263f989759fcf30@haskell.org> Message-ID: <062.52af99991d0ba9d81ccabc2cf4069b51@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give a concrete example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 08:33:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 08:33:39 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.21aaca30765cc68457b593207415b9e5@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.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): See also [http://www.haskell.org/pipermail/ghc- devs/2014-August/006147.html this thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 08:36:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 08:36:39 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.74d1ea1266e36a9b011a1b43a09a0944@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.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): Another thought. Regardless of what we do here, it seems likely that GHC will sometimes make the wrong choice. So we should give the programmer a way to make the "right" choice. Example. Suppose `[1..10000]` is floated out and shared. Then we should provide `duplicableEnumFromTo 1 10000` which means "please don't try to share me; instead fuse me with my consumers, even if that loses sharing". OK so you lose the nice notation, but you get to say what you want. (And if we switch so that `[1..1000]` is by-default not-shared, then we should provide a way force it to be shared: `nonDuplicableEnumFromTo 1 1000`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 08:41:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 08:41:53 -0000 Subject: [GHC] #9519: Add a way to mask thread preemption via fired timer for a computation Message-ID: <047.26171a8aa89618b26a4ae216870ee32e@haskell.org> #9519: Add a way to mask thread preemption via fired timer for a computation -------------------------------------+------------------------------------- Reporter: abbradar | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------+------------------------------------- This follows haskell-cafe discussion [http://www.haskell.org/pipermail /haskell-cafe/2014-August/115656.html]. In brief: some C libraries (for example, SDL) use thread-local variables for error state of the last call. Without some way to temporarily mask timer-based lightweight thread preemption on one OS thread, there is no safe way to use such libraries and retrieve errors aside from using a global MVar (which will block all calls, not just ones on the same OS thread). For "errno" variable from C standard library, this is handled explicitly in RTS by saving its state for each lightweight thread. So the proposal is: add new prims (something in lines of "maskPreemption#", "unmaskPreemption#" and "getPreemptionState#") which will make a computation not preemptable via fired timer and temporarily attached to one OS thread, and corresponding functions in Control.Concurrent. They should be able to be used together with "Control.Exception.mask" to also block async exceptions, if this is needed. (I'm sorry if I've misunderstood something or did something the wrong way; I don't know the internal workings of RTS and this is my first GHC bug report). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 08:50:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 08:50:19 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.f3830e2e164855a37b085fcfbd68e873@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.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 snoyberg): * cc: snoyberg (added) Comment: Following up on a separate discussion on the haskell-cafe, I have a possibly related case: {{{#!hs main :: IO () main = printLen >> printLen printLen :: IO () printLen = lengthM 0 [1..40000000 :: Int] >>= print lengthM :: Monad m => Int -> [a] -> m Int lengthM cnt [] = return cnt lengthM cnt (_:xs) = cnt' `seq` lengthM cnt' xs where cnt' = cnt + 1 }}} On my system, this takes almost 1.2GB of memory. If I comment out the second call to `printLen`, it takes 44KB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 10:22:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 10:22:13 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.ec43910274e4921ffc789707787df7b1@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: dcoutts => duncan Comment: refold: It's a good question, and thinking about this question more carefully, no, this patchset alone doesn't give us the capability. The problem is that GHC is still tightly coupled to ghc-pkg, but ghc-pkg still has a Cabal dependency and thus if you update Cabal, you also need to upgrade ghc-pkg. So, the only way to make Cabal separately upgradeable is by siphoning ghc-pkg off into a proper package, relaxing the tight coupling and upgrading it when you upgrade Cabal. duncan, can we do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 10:27:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 10:27:14 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.3dfb72ff2e7e86bdf1ca10077e2ef5d5@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by ezyang): duncan: I also realized I had another major design question about the new binary package format. In your design doc, you state that the reason we need to store Cabal's information in the binary package database is because ghc-pkg needs to be able to regurgitate the information later. However, isn't the textual files in the database intended to be the "primary" representation, in which case can't ghc-pkg just hit the actual filesystem rather than using the binary package database? Normally, I'd be indifferent, but if we can reduce the size of the binary package database that will improve GHC startup times. And it's not like we need to make sure ghc-pkg's 'describe' functionality is blazingly fast... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 11:11:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 11:11:39 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.b3e3e70d803c5c3f027cef8a8e6aafcc@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.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: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"9cf5906b692c31b7ec67856b0859cb0e33770651/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9cf5906b692c31b7ec67856b0859cb0e33770651" Make worker/wrapper work on INLINEABLE things This fixes a long-standing bug: Trac #6056. The trouble was that INLINEABLE "used up" the unfolding for the Id, so it couldn't be worker/wrapper'd by the strictness analyser. This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE instead, so it can later be specialised. However, that doesn't completely solve the problem, because the dictionary argument (which the specialiser treats specially) may be strict and hence unpacked by w/w, so now the worker won't be specilialised after all. Solution: never unpack dictionary arguments, which is done by the isClassTyCon test in WwLib.deepSplitProductType_maybe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 11:22:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 11:22:22 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.2d6a29c9e98934ec89796bde08834477@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by refold): ezyang: What I had in mind was upgrading, say, Cabal 1.22 -> 1.24 when going from GHC 7.10.2 to GHC 7.10.3. Since GHC API will no longer depend on Cabal, this should be less of a problem. > So, the only way to make Cabal separately upgradeable is by siphoning ghc-pkg off into a proper package, relaxing the tight coupling and upgrading it when you upgrade Cabal. Is splitting the parts of Cabal ghc-pkg uses into a separate library out of the picture? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 11:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 11:55:40 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.928207ad080249525033fc27efea783a@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by ezyang): > What I had in mind was upgrading, say, Cabal 1.22 -> 1.24 when going from GHC 7.10.2 to GHC 7.10.3. Since GHC API will no longer depend on Cabal, this should be less of a problem. Well, it would still necessitate bumping up GHC's internal copy of Cabal, since ghc-pkg needs to be compiled with the right version. > Is splitting the parts of Cabal ghc-pkg uses into a separate library out of the picture? Well, if those bits don't change, you can probably use ghc-pkg with a new Cabal and it probably will work. The whole point is if those types change then you have to clue in ghc-pkg. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 12:49:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 12:49:26 -0000 Subject: [GHC] #7297: LLVM incorrectly hoisting loads In-Reply-To: <045.bd816ad08f5119bccde9f8a70a030128@haskell.org> References: <045.bd816ad08f5119bccde9f8a70a030128@haskell.org> Message-ID: <060.a0545d04c4954503adc225bb0f44ef4a@haskell.org> #7297: LLVM incorrectly hoisting loads -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | 367_letnoescape | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"11455684212b2bbf76d5eb20fdd2d01fbdf21311/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="11455684212b2bbf76d5eb20fdd2d01fbdf21311" testsuite: disable T367_letnoescape on 'optllvm' Known Issue #7297 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 13:19:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 13:19:16 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.a40aab0514ed793d55389d3e7e79c935@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by duncan): ezyang and I discussed this on IRC, but for the record... Replying to [comment:26 ezyang]: > duncan: I also realized I had another major design question about the new binary package format. In your design doc, you state that the reason we need to store Cabal's information in the binary package database is because ghc-pkg needs to be able to regurgitate the information later. However, isn't the textual files in the database intended to be the "primary" representation, in which case can't ghc-pkg just hit the actual filesystem rather than using the binary package database? It could read the text files, but this would be slower than using the binary cache. The performance of ghc-pkg dump is actually important. It's used by cabal to get the installed packages. > Normally, I'd be indifferent, but if we can reduce the size of the binary package database that will improve GHC startup times. And it's not like we need to make sure ghc-pkg's 'describe' functionality is blazingly fast... The binary file is structured so that the part that ghc reads comes first. So the extra data for ghc-pkg to read back will not affect the time taken to read the part for ghc. ghc-pkg describe does not need to be fast, but ghc-pkg dump does (at least reasonably so). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 13:24:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 13:24:49 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.bf8adf9a23d6c805b2be4d5f16a37580@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by duncan): Replying to [comment:25 ezyang]: > refold: It's a good question, and thinking about this question more carefully, no, this patchset alone doesn't give us the capability. The problem is that GHC is still tightly coupled to ghc-pkg, but ghc-pkg still has a Cabal dependency and thus if you update Cabal, you also need to upgrade ghc-pkg. So, the only way to make Cabal separately upgradeable is by siphoning ghc-pkg off into a proper package, relaxing the tight coupling and upgrading it when you upgrade Cabal. duncan, can we do this? I don't think this is true. If you upgrade Cabal you do not need to upgrade ghc-pkg. Rememer that Cabal can work with older (and often newer) versions of ghc. It is in fact not tightly coupled with ghc-pkg, because the coupling is only via the external textual representation of the `InstalledPackageInfo` which gives us a lot of room for forwards and backwards compatability. The only times when they're more strongly coupled is when ghc-pkg requires new fields in the `InstalledPackageInfo`. In that case you need to be using a newer Cabal. So as far as I can see, upgrading Cabal will still be fine under this new scheme, with the bonus that the ghc library itself will not use it. GHC will still ship with Cabal, but you could add a new version. Could you take an existing ghc binary tarball and modifiy it to include a newer Cabal lib without breaking things? Probably yes. No other libraries that ghc ships will depend on Cabal, so they would not break. And it would be fine for ghc-pkg to have been built against the older Cabal, so long as it is statically linked against Cabal (or the older Cabal .so is still included). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 13:42:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 13:42:01 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once Message-ID: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 13:42:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 13:42:22 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.4bdfd297dc5aee6fb6f09aa4494e2204@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 cactus): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 14:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 14:03:22 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.92033f9bc0a20090dd4bca7df8f518af@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I don't understand `conduit`. But looking at `bad.core` I see: * `main3` is called twice (in the RHS of `main1`). This corresponds to the two calls of `action`. * So I wonder if there are any values shared between call calls of `main3`. These will be top-level CAFs. * Aha yes! `main5` is shared. But it's fine: it is simply `Done ()`. * Aha again! We see {{{ main6 :: Data.Conduit.Internal.Pipe Data.ByteString.Internal.ByteString Data.ByteString.Internal.ByteString Data.Void.Void () IO Int main6 = main9 main8 (main7 `cast` ...) }}} So if `main6` generates a big data structure, it will be retained across both calls. Back to you -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 14:04:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 14:04:30 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.b110f79d47c74416c0792f542a2827a0@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): OK, I've got a version of this that only relies on `base` now: {{{#!hs import System.IO (withBinaryFile, IOMode (ReadMode), Handle, hIsEOF, hGetChar) main :: IO () main = do action --action action :: IO () action = do _ <- withBinaryFile "1mb" ReadMode $ \h -> connect (sourceHandle h) sinkCount return () data Conduit i o m r = Pure r | M (m (Conduit i o m r)) | Await (i -> Conduit i o m r) (Conduit i o m r) | Yield (Conduit i o m r) o sourceHandle :: Handle -> Conduit i Char IO () sourceHandle h = loop where loop = M $ do isEof <- hIsEOF h if isEof then return $ Pure () else do c <- hGetChar h return $ Yield loop c sinkCount :: Monad m => Conduit i o m Int sinkCount = loop 0 where loop cnt = Await (\_ -> loop $! cnt + 1) (Pure cnt) connect :: Monad m => Conduit a b m r' -> Conduit b c m r -> m r connect _ (Pure r) = return r connect (Yield left b) (Await right _) = connect left (right b) connect (Pure x) (Await _ right) = connect (Pure x) right connect (M mleft) right = mleft >>= flip connect right }}} Same behavior regarding `action`. I'll attach a heap profile with the large memory usage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 14:08:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 14:08:05 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.6aaf3ebdface4f57f22e34e6a5c3c7d2@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): > So if `main6` generates a big data structure, it will be retained across both calls. Well, that's sort of the idea: conduit is essentially a free monad, and it's evaluated by interpreting steps like "wait for next input" or "provide next value." What *should* be happening is that it creates a value indicating the next step, and that value is immediately consumed and garbage collected. Instead, for some reason it's maintaining this structure between multiple calls, even though the two data structures will not match (not that the `Handle` used by each loop will be different). Hopefully the base-only version of the code will demonstrate the issue more clearly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 14:27:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 14:27:31 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.efd51e6a27dd9a1b3776493fe5315592@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): Apologies if this is becoming repetitive, but here's a slightly simpler version demonstrating the same issue: {{{#!hs import System.IO data Sink i r = Sink (i -> Sink i r) r sinkCount :: Sink i Int sinkCount = loop 0 where loop cnt = Sink (\_ -> loop $! cnt + 1) cnt feed :: Handle -> Sink Char r -> IO r feed h = loop where loop (Sink f g) = do eof <- hIsEOF h if eof then return g else do c <- hGetChar h loop $! f c action :: IO () action = withBinaryFile "1mb" ReadMode $ \h -> do feed h sinkCount return () main :: IO () main = do action action }}} The following code, however, does *not* demonstrate the problem: {{{#!hs import System.IO data Sink i r = Sink (i -> Sink i r) r sinkCount :: Sink i Int sinkCount = loop 0 where loop cnt = Sink (\_ -> loop $! cnt + 1) cnt feed :: Sink Char r -> IO r feed = loop 10000000 where loop 0 (Sink _ g) = return g loop i (Sink f _) = loop (i - 1) (f 'A') action :: IO () action = do feed sinkCount return () main :: IO () main = do action action }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 17:39:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 17:39:59 -0000 Subject: [GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask In-Reply-To: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> References: <044.1d01b7c46053b095d721dbccbd1f2dd3@haskell.org> Message-ID: <059.7f554803301edfd42a06240726f99da2@haskell.org> #9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.2 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: Phab:D181 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 17:50:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 17:50:33 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.504c65d55169d62d1cd1ff258035c1a3@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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): If I understand correctly, then, a representational role will allow users to get out-of-bounds errors, right? This would happen in the contrived scenario in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 18:00:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 18:00:44 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.6c9294c2f5704b7cd9f5f3034b406c42@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by meteficha): * cc: meteficha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 19:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 19:26:07 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.9857f6e88a7c929b75919b0232279ea9@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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 carter): @Richard, in Reid's example, that would be for Storable rather than Unboxed arrays (at least if I'm understanding this thread correctly, and thus because Storables are just wrapped up pointers, it falls under the same onus as Ptr's rather than Unboxed arrays?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 19:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 19:40:53 -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.215b7d7d434f78dc42999d66807c2485@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): To summarise: Both the simulator and device builds of GHC 7.8.3 (for iOS) behave incorrectly when compiled with LLVM 3.0. None of the suggested alterations fixes this. The simulator builds with LLVM 3.4 and behaves correctly. The device version fails to build with 3.4. Can anyone suggest which combination of GHC branch and recent LLVM I should be trying with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 19:45:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 19:45:08 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.3cdc0ee699aaf8e6f1e24afae26b98d7@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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 rwbarton): Replying to [comment:6 goldfire]: > If I understand correctly, then, a representational role will allow users to get out-of-bounds errors, right? This would happen in the contrived scenario in comment:3. You won't actually get an out-of-bounds ''error'', you'll simply read outside the memory area allocated to the array (which could cause a segfault, or leak other data, or just return nonsense). Regarding `UArray` specifically, I believe it's true that all the different existing instances of `IArray UArray` are for non- representationally equal types (although under the hood many are actually represented identically, e.g. `data Word8 = W8# Word#`, `data Word16 = W16# Word#`; I believe these are still not inter-`coerce`-ible, though). And in order to write your own `IArray` instance you have to define functions with names like `unsafeAt`. So a representational role for `UArray` would be justifiable if ensuring that the in-array representation is identical is considered to be part of the contract when defining an `IArray` instance for a newtype. (One that would be satisfied automatically by GND.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 19:50:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 19:50:49 -0000 Subject: [GHC] #9393: execvpe should handle ENOTDIR In-Reply-To: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> References: <044.de71ccdfac1cf39975dbc19d1eedf841@haskell.org> Message-ID: <059.8fea3561c62658ece6b757558ca3515b@haskell.org> #9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 libraries/unix | 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 thoughtpolice): * status: patch => upstream * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 20:07:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 20:07:51 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.ab783b10be46b34a4befaf147e3e5f15@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): As pointed out by Bryan Vicknair in the cafe thread, my first example in my previous comment does not always leak memory. In particular, I had to turn on optimizations (either `-O` or `-O2`) to get it to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 20:52:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 20:52:20 -0000 Subject: [GHC] #9449: GHC.Prim documentation says "Safe Inferred" In-Reply-To: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> References: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> Message-ID: <062.f8b13e9d6482f700149749b6e7e196d0@haskell.org> #9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: low | 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: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D182 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D182 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 20:52:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 20:52:35 -0000 Subject: [GHC] #9449: GHC.Prim documentation says "Safe Inferred" In-Reply-To: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> References: <047.6ad8c2a212ab3e49ebf79357b664b6f9@haskell.org> Message-ID: <062.5d2bafaae3c2cf2e58849299ddccb3f3@haskell.org> #9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: | Version: 7.8.2 Documentation | 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: Phab:D182 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 28 22:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Aug 2014 22:53:25 -0000 Subject: [GHC] #9521: ghc doesn't pass flags to ld via -optl Message-ID: <054.b29702fc7fd742b8031e22836f87b4bf@haskell.org> #9521: ghc doesn't pass flags to ld via -optl -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm compiling i386 binaries on amd64 linux --- already overcame #9421, but still not there. When I do the following (using a i386 GHC 7.8.3 on a 64 bit Ubuntu) {{{ ~/r/LambdaHack$ cabal install haskell-lexer-1.0 -j1 --ghc- option="-optc-m32" --ghc-option="-opta-m32" --ghc-option="-optl-m32" --ghc-option="-optl-arch\ i386" --ghc-option="-optl-m\ elf_i386" --ghc- option="-optl-Wl,-m32" -v3 >& log }}} I get the attached log with, in particular, these lines: {{{ ("/home/mikolaj/local/bin/ghc",["-c","/tmp/4707.c","-o","/tmp/4707.o","-optc-m32","-opta-m32","-optl-m32 ","-optl-arch\\ i386","-optl-m\\ elf_i386","-optl-Wl,-m32"]) ("/usr/bin/ld",["-x","-r","/tmp/4707.o","-o","/tmp/4708.o"]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 00:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 00:04:34 -0000 Subject: [GHC] #9521: ghc doesn't pass flags to ld via -optl In-Reply-To: <054.b29702fc7fd742b8031e22836f87b4bf@haskell.org> References: <054.b29702fc7fd742b8031e22836f87b4bf@haskell.org> Message-ID: <069.e10b13352c1d1194b9484176340b74e4@haskell.org> #9521: ghc doesn't pass flags to ld via -optl -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: new => closed * resolution: => invalid Comment: I panicked, there is probably no bug. The offending call to /usr/bin/ld is done directly by cabal, not by ghc, and so I needed to pass --ld-option as well: {{{ cabal install haskell-lexer-1.0 -j1 --ghc-option="-optc-m32" --ghc- option="-opta-m32" --ghc-option="-optl-m32" --ld-option="-melf_i386" }}} This works and so compiling i386 binaries on amd64 Linux finally works for me. BTW, for completeness, I also had to do {{{ sudo apt-get install libgmp-dev:i386 }}} which unfortunately breaks compilation of amd64 binaries, or hack around as follows {{{ sudo ln -s /usr/lib/i386-linux-gnu/libgmp.so.10.0.2 /usr/lib/i386-linux- gnu/libgmp.so }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 02:14:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 02:14:59 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.f3cf7128e1436372b161860d077b97f0@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:29 duncan]: > It could read the text files, but this would be slower than using the binary cache. The performance of ghc-pkg dump is actually important. It's used by cabal to get the installed packages. Maybe Cabal should have its own binary cache for the data it gets out of `ghc-pkg dump`? We can check whether compiler's package DB is older than our cache and only use the slow path (`ghc-pkg dump`) when it's not. Perhaps we could also share the `Binary` instance for `InstalledPackageInfo` between `Cabal` and `ghc-pkg`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 08:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 08:39:19 -0000 Subject: [GHC] #9522: SPECIALISE pragmas for derived instances Message-ID: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> #9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 08:43:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 08:43:23 -0000 Subject: [GHC] #9522: SPECIALISE pragmas for derived instances In-Reply-To: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> References: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> Message-ID: <061.355758858d1523aa6d3bb61f799118dd@haskell.org> #9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- 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: > In package `ghc-prim`, in `GHC.Classes` we have > {{{ > instance (Eq a) => Eq [a] where > {-# SPECIALISE instance Eq [[Char]] #-} > {-# SPECIALISE instance Eq [Char] #-} > {-# SPECIALISE instance Eq [Int] #-} > [] == [] = True > (x:xs) == (y:ys) = x == y && xs == ys > _xs == _ys = False > }}} > The `SPECIALISE instance` pragmas instantiate the code for these > commonly-used types. > > But for tuples we use `deriving`: > {{{ > deriving instance (Eq a, Eq b) => Eq (a, b) > }}} > and many more similar. There is no way to add a `SPECIALISE instance` > pragma for a derived instance. This is bad, because they are heavily > used. > > It should probably be possible to have a top-level > {{{ > {-# SPECIALISE instance Eq (Int, Bool) #-} > }}} > even in another module (as we can now do for functions. To do this > right, we'd need to make the code for derived methods `INLINEALBE`. New description: In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. You can see the lossage from messages lie {{{ WARNING: file compiler/specialise/Specialise.lhs, line 673 specImport discarding: GHC.Classes.$w$c== :: forall a b. (Eq a, Eq b) => a -> b -> a -> b -> Bool @ Module.Module @ Module.Module Module.$fEqModule Module.$fEqModule }}} which says that we will end up calling `$w$c==` for pairs of modules, passing dictionaries to compare the modules for equality. These messages show up when compiling the libraries if you build your stage1 compiler with `-DDEBUG`. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 09:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 09:17:46 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.c4397286eb58bb44ed395a81dfefe700@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by duncan): @simonpj, @ezyang thanks for all the updates to the CabalDependency wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 09:19:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 09:19:50 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.060ed69668b342a74661fedf06664678@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by duncan): Replying to [comment:31 refold]: > Maybe Cabal should have its own binary cache for the data it gets out of `ghc-pkg dump`? We can check whether compiler's package DB is older than our cache and only use the slow path (`ghc-pkg dump`) when it's not. Perhaps we could also share the `Binary` instance for `InstalledPackageInfo` between `Cabal` and `ghc-pkg`. I don't think cabal calling `ghc-pkg dump` is currently a performance bottleneck. If it becomes one, there's several things we can do to improve it before adding caching. In a sense we already have a cache, when we `cabal configure` we read it only once and don't re-read it for `cabal build`. When installing a bunch of packages, it's read once for dep planning, and again for each package installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 09:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 09:24:01 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.484dc165e080eafb45c8f7b6aaeb11ca@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: D172 | -------------------------------------+------------------------------------- Comment (by simonpj): I hope that the [wiki:CabalDependency] page captures everything so far in this ticket. If not, yell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 10:59:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 10:59:59 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.9bb8548ee6f8ab02808eaf82034a4d23@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Here is the trivial workaround (perhaps I should add it to the wiki somewhere and then close the ticket?): {{{ CFLAGS=-m32 ./configure --prefix=..... }}} Now I can compile many packages and the 32bit executables work (e.g., alex, happy). I still struggle with gtk2hs and I haven't tried beasts like yesod, etc, though. The command I use is {{{ cabal install --ghc-option="-optc-m32" --ghc-option="-opta-m32" --ghc- option="-optl-m32" --ld-option="-melf_i386" }}} == Long story == The workaround is inspired by https://ghc.haskell.org/trac/ghc/ticket/8910 and http://www.haskell.org/pipermail/glasgow-haskell- users/2012-February/022014.html I had to install many -dev:i386 versions of libraries on my Ubuntu to make it work. The most problematic was libgmp-dev, since my Ubuntu only tolerates amd64 or i386 version of this lib at once (zlib1g-dev:i386 didn't have that problem). I ended up adding a hacky symlink instead of the -dev:i386 version: {{{ sudo ln -s /usr/lib/i386-linux-gnu/libgmp.so.10.0.2 /usr/lib/i386-linux- gnu/libgmp.so }}} == The remaining gtk2hs problem == This is probably a bug in gtk2hs-buildtools (I reinstalled them for 32bits with many extra flags, but no improvement), but I won't report it on gtk2hs issue tracker until I research a bit more. I try monstrosities like {{{ CFLAGS=-m32 cabal install glib -j1 --ghc-option="-optc-m32" --ghc- option="-opta-m32" --ghc-option="-optl-m32" --ld-option="-melf_i386" -v3 --gcc-option="-m32" --configure-option="CFLAGS=-m32" --ghc-option="-optl- Wl,-melf_i386" }}} but I'm still getting {{{ /tmp/glib-0.13.0.1-1099/glib-0.13.0.1/dist/setup/setup configure --verbose=3 --ghc --prefix=/mikolaj/.cabal --bindir=/mikolaj/.cabal/bin --libdir=/mikolaj/.cabal/lib --libsubdir=i386-linux- ghc-7.8.3/glib-0.13.0.1 --libexecdir=/mikolaj/.cabal/libexec --datadir=/mikolaj/.cabal/share --datasubdir=i386-linux-ghc-7.8.3/glib-0.13.0.1 --docdir=/mikolaj/.cabal/share/doc/i386-linux-ghc-7.8.3/glib-0.13.0.1 --htmldir=/mikolaj/.cabal/share/doc/i386-linux- ghc-7.8.3/glib-0.13.0.1/html --haddockdir=/mikolaj/.cabal/share/doc/i386-linux- ghc-7.8.3/glib-0.13.0.1/html --sysconfdir=/mikolaj/.cabal/etc --configure-option=CFLAGS=-m32 --user --flags=closure_signals --extra-prog-path=/mikolaj/.cabal/bin --constraint=utf8-string ==0.3.8 --constraint=text ==1.1.1.3 --constraint=containers ==0.5.5.1 --constraint=bytestring ==0.10.4.0 --constraint=base ==4.7.0.1 --disable-tests --disable-benchmarks --gcc-option=-m32 --ghc-option=-optc-m32 --ghc-option=-opta-m32 --ghc-option=-optl-m32 --ghc-option=-optl-Wl,-melf_i386 --ld- option=-melf_i386 [1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist/setup- wrapper/Gtk2HsSetup.o ) /tmp/ghc1232_0/ghc1232_4.s: Assembler messages: /tmp/ghc1232_0/ghc1232_4.s:43:0: Error: invalid instruction suffix for `push' }}} I haven't looked inside the generated files nor inside the gtk2hs- buildtools yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 11:30:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 11:30:04 -0000 Subject: [GHC] #9220: type roles for unboxed arrays In-Reply-To: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> References: <047.75e5b5ededd5cd148e56ebf27d2be649@haskell.org> Message-ID: <062.73332f6c965ebe51de3acbf43dc545f1@haskell.org> #9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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): Ah -- that makes good sense then. Thanks, rwbarton. I'll take care of this in my next round of GHC hacking, sometime after ICFP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 13:14:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 13:14:07 -0000 Subject: [GHC] #9514: Haddock panics when exporting a module with pattern synonyms In-Reply-To: <051.724e8731cbd989337a8289cb4a174715@haskell.org> References: <051.724e8731cbd989337a8289cb4a174715@haskell.org> Message-ID: <066.b7ba5971f222a849b12d54a9151b18c8@haskell.org> #9514: Haddock panics when exporting a module with pattern synonyms -------------------------------------+------------------------------------- Reporter: | Owner: cactus Artyom.Kazak | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: haddock, pattern Resolution: duplicate | synonyms Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => closed * resolution: => duplicate Comment: Duplicate of 9417 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 13:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 13:52:38 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.75845dee5379fd13715cfd6c686e6888@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -------------------------------------+------------------------------------- Reporter: | Owner: simonmar RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bananu7): I'm getting this under `Lens` too (pretty much the same errors, so no point copying the whole thing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:09:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:09:31 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.0c6b449f4ed5d1e33e8cadb05b432b8e@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 Dr. ERDI Gergo ): In [changeset:"f0db1857b053597e9ac43d9ce578e5f5fa0545cb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0db1857b053597e9ac43d9ce578e5f5fa0545cb" Include pattern synonyms as AConLikes in the type environment, even for simplified/boot ModDetails (fixes #9417) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:10:07 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.f51f720c3021a37421647d2f80d4baab@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:17:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:17:00 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.b9ee0728ca32762d543b316e3106a31f@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.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: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"e5f766c392c8c1cb329e1409102b5655c3c253c9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e5f766c392c8c1cb329e1409102b5655c3c253c9" Give the worker for an INLINABLE function a suitably-phased Activation See Note [Activation for INLINABLE worker]. This was preventing Trac #6056 from working. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:17:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:17:00 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.da7f4c3bb2033a011575a3c9ae9c7cc1@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. --------------------------------------------+------------------------------ Reporter: milan | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.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: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"393506269315bca66aae91517b75e0a003470c84/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393506269315bca66aae91517b75e0a003470c84" Finally! Test Trac #6056 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:19:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:19:37 -0000 Subject: [GHC] #6056: INLINABLE pragma prevents worker-wrapper to happen. In-Reply-To: <044.48485356203668916cbd990ce18921d0@haskell.org> References: <044.48485356203668916cbd990ce18921d0@haskell.org> Message-ID: <059.94d14a934a559bf8f151d0ba185fea17@haskell.org> #6056: INLINABLE pragma prevents worker-wrapper to happen. -------------------------------------+------------------------------------- Reporter: milan | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | simplCore/should_compile/T6056 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T6056 * resolution: => fixed Comment: I think I have finally nailed this. Yell if it doesn't work for you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 16:28:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 16:28:28 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.9c8864a9cbd47a3a10250630a124cdc7@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: 5539 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Urgh. I get this {{{ Resolving dependencies... Downloading SFML-0.2.0.0... Configuring SFML-0.2.0.0... cabal: Missing dependencies on foreign libraries: * Missing C libraries: csfml-window, csfml-system, csfml-graphics, csfml-network, csfml-audio This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. Failed to install SFML-0.2.0.0 cabal: Error: some packages failed to install: SFML-0.2.0.0 failed during the configure step. The exception was: ExitFailure 1 }}} Are those C packages essential? It would be good to be able to reproduce this.... 1630 is rather big! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 18:23:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 18:23:30 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation Message-ID: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Documentation | 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: -------------------------------------+------------------------------------- In `GHC.Generics`: The types `S`, `C` and `R` are once again type-level proxies, just used to create several variants of `M1`. The `R`, it seems, is supposed to be a `D`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 19:58:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 19:58:09 -0000 Subject: [GHC] #9396: Code cleanup: warning: use of GNU old-style field designator extension In-Reply-To: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> References: <042.7a09ae20cce6bfb1806d3d05f7f34b96@haskell.org> Message-ID: <057.2cd86c9101d708686e6997c2503f9e1b@haskell.org> #9396: Code cleanup: warning: use of GNU old-style field designator extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 20:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 20:01:13 -0000 Subject: [GHC] #9465: configure: sed: illegal option -- r In-Reply-To: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> References: <042.ece74089881f6a1c648e55d230336c1b@haskell.org> Message-ID: <057.f033d58d375aebc1231679033aee3aa8@haskell.org> #9465: configure: sed: illegal option -- r -------------------------------------+------------------------------------- Reporter: jrp | Owner: pgj Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: sed Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 20:41:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 20:41:29 -0000 Subject: [GHC] #9524: GHC uses wrong linker when cross compiling Message-ID: <049.96f062346f8aab14c3c1ff251a788093@haskell.org> #9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Greetings, I tried to compile a cross compiler for x86_64-w64-mingw32. Most of GHC compiles fine. However, after a while there's an error that ld can't find a reference to "GetModuleFileNameW". I tried compiling a dummy C program with that symbol and it compiles fine. My guess is that GHC is using the wrong linker during cross-compiling, whereas GCC uses the right one. But I may be totally wrong, so please don't rely on that judgement. The log of the make run is attached. Regards Sven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 29 22:00:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Aug 2014 22:00:09 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.7f9b42657042616044b359a7e3a760d2@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): This is now documented on [wiki:Building/Compiling32on64 the wiki]. The problem with GTK is indeed in the gtk2hs setup scripts: https://github.com/gtk2hs/gtk2hs/issues/49 This suggests that on multi-arch OSes it would be helpful if GHC called gcc and linker (and itself) with the flags implied by the target arch. I guess we don't support gcc and ld old enough to reject such options, so the only problem is verbosity of the calls when they are shown during debugging. But then, having options spelled out explicitly tends to be good for debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 02:05:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 02:05:31 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.cd2628e98df7e69b4b269667127a2bbd@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | 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 | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:4 snoyberg]: Without looking at the core, {{{sinkCount}}} has the potential to become a large shared data structure, if the {{{loop $! cnt + 1}}} part is floated out like so: {{{ sinkCount :: Sink i Int sinkCount = loop 0 where loop cnt = let sink' = loop $! cnt + 1 in Sink (\_ -> sink') cnt }}} Then the run-time representation of {{{(\_ -> sink')}}} is a closure that points to the next sink, {{{sink'}}}. The first time {{{sinkCount}}} is used it'll produce many sinks {{{(Sink (\_ -> sink') cnt)}}} for increasing counts, each linking to the next. Ideally, {{{sinkCount}}} and {{{feed}}} should be fused, but that requires inlining parts of {{{sinkCount}}} which given its recursive definition is tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 05:25:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 05:25:11 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.e9a02d0c7817413da439a83077a8e24e@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 cactus): Could someone who knows his way around in Haddock add this as a test case please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 10:57:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 10:57:19 -0000 Subject: [GHC] #9525: +RTS -xc stack trace sometimes reported twice Message-ID: <043.b89cf286c7ba7d4a16178fcdcd90d766@haskell.org> #9525: +RTS -xc stack trace sometimes reported twice -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: profiling, stack | Operating System: trace, error | Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance. Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected: {{{#!haskell f :: Int -> Int f = error "hello" main = print (f 20) }}} {{{ ? ghc_patch ./error +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: Main.f, called from Main.CAF --> evaluated by: Main.main, called from Main.CAF error: hello }}} But if I change it to this: {{{#!haskell f :: Int -> Int f x = let x = x + 20 in x main = print (f 20) }}} Stack trace is reported twice: {{{ ? ghc_patch ./error +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.f.x, called from Main.f, called from Main.main, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.f.x, called from Main.f, called from Main.main, called from Main.CAF error: <> }}} Can anyone confirm that this is really a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 11:34:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 11:34:08 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.7a9d111f6bae8c280fee037834e76fb0@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: pattern synonyms 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 Fuuzetsu): I don't have a HEAD build at the moment. You can simply stick the Haskell source files into {{{html-test/src}}}, run the (Haddock) tests, eye the results in {{{html-test/out}}} and if you're happy with them either copy the results to {{{html-test/ref}}} or use the {{{accept.lhs}}} file to do so for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 15:20:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 15:20:53 -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.2f5b218427fb573c88b1fb52dbefad11@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: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => D185 Comment: I propose the following workaround: https://phabricator.haskell.org/D185 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 15:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 15:46:22 -0000 Subject: [GHC] #9526: Add missing Generic instances in base Message-ID: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Most primitive types (`Int`, `Char`, etc.) have a GHC.Generics.Generic instance, but some are missing, such as `Integer` and the various `Word*` data types. We should consistently have instances for all primitive types offered by base, since they are required if you want to derive a Generic instance for any type that contains them. I boldly set the milestone to 7.10 because I naively assume this should be straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 15:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 15:49:28 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH Message-ID: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: 9526 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Template Haskell has a number of huge data types that would be much easier to work with if they had `Generic` instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 15:51:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 15:51:23 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.9626596ac15d837d2e2687ab458f99ad@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9527 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * owner: => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 17:33:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 17:33:49 -0000 Subject: [GHC] #9528: typo in man-page/docs Message-ID: <048.b394457866f8d569617be702e8907986@haskell.org> #9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- "rrestriction" in ghc/docs/users_guide/flags.xml -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 17:55:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 17:55:43 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.f4a555be0be804d3645948c48969fe3c@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9527 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 19:44:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 19:44:03 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.6cc8493380864d0f761aea3c951bbe2f@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I've worked around the gtk problems by replacing ghc with {{{ ghc-7.8.3 -optc-m32 -opta-m32 -optl-m32 $@ }}} and by setting up the following symlinks (installing both i386 and amd64 versions of gtk dev libs is not supported on my Ubuntu): {{{ sudo ln -s /lib/i386-linux-gnu/libglib-2.0.so.0 /usr/lib/i386-linux- gnu/libglib-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 /usr/lib/i386 -linux-gnu/libgobject-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgio-2.0.so.0 /usr/lib/i386-linux- gnu/libgio-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libcairo.so.2 /usr/lib/i386-linux- gnu/libcairo.so sudo ln -s /usr/lib/i386-linux-gnu/libpango-1.0.so.0 /usr/lib/i386-linux- gnu/libpango-1.0.so sudo ln -s /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 /usr/lib/i386 -linux-gnu/libpangocairo-1.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 /usr/lib/i386 -linux-gnu/libgthread-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 /usr/lib/i386 -linux-gnu/libgtk-x11-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 /usr/lib/i386 -linux-gnu/libgdk-x11-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libatk-1.0.so.0 /usr/lib/i386-linux- gnu/libatk-1.0.so sudo ln -s /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 /usr/lib/i386 -linux-gnu/libpangoft2-1.0.so sudo ln -s /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 /usr/lib/i386 -linux-gnu/libgdk_pixbuf-2.0.so sudo ln -s /usr/lib/i386-linux-gnu/libfreetype.so.6 /usr/lib/i386-linux- gnu/libfreetype.so sudo ln -s /usr/lib/i386-linux-gnu/libfontconfig.so.1 /usr/lib/i386 -linux-gnu/libfontconfig.so sudo ln -s /usr/lib/i386-linux-gnu/libX11.so.6 /usr/lib/i386-linux- gnu/libX11.so }}} The GTK calls in the generated binary work great and the binary is reported as {{{ ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x46cf78948f9bad6f6beed815d6c0f71679830324, stripped }}} However, there is an unrelated problem: whenever compressions is required the binary crashes with {{{ user error (Codec.Compression.Zlib: incompatible zlib version) }}} The ldd utility reports {{{ libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7025000) }}} recompiling zlib package with zlib1g-dev:i386 or without and with various hacky symlinks doesn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 20:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 20:07:13 -0000 Subject: [GHC] #9421: magic number mismatch when installing 32bit on 64bit machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.d632caf0e87fc9187168113a5f15ae4d@haskell.org> #9421: magic number mismatch when installing 32bit on 64bit machine -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: Installing | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): To work around zlib problems I had to add hsc2hs options: {{{ cabal install zlib --ghc-option="-optc-m32" --ghc-option="-opta-m32" --ghc-option="-optl-m32" --ld-option="-melf_i386" --hsc2hs-options="-- cflag=-m32 --lflag=-m32" }}} This was inspired by {{{ http://www.haskell.org/pipermail/glasgow-haskell- users/2009-November/018070.html }}} and was needed despite {{{ https://ghc.haskell.org/trac/ghc/ticket/3400#comment:16 }}} Now everything works correctly for me. Next up for testing would be a TH heavy package or just a very large application. Yesod comes to mind. Please report here if you try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 20:59:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 20:59:14 -0000 Subject: [GHC] #9529: Clean up cseProgram Message-ID: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> #9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 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: -------------------------------------+------------------------------------- I think this should be a no-brainer: Replace {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram binds = cseBinds emptyCSEnv binds cseBinds :: CSEnv -> [CoreBind] -> [CoreBind] cseBinds _ [] = [] cseBinds env (b:bs) = (b':bs') where (env1, b') = cseBind env b bs' = cseBinds env1 bs }}} with {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram = snd . mapAccumL cseBind emptyCSEnv }}} I'll attach a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 22:20:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 22:20:21 -0000 Subject: [GHC] #9529: Clean up cseProgram In-Reply-To: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> References: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> Message-ID: <060.f33c934ba1f57d2afb1be66aaa5226cc@haskell.org> #9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 22:48:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 22:48:49 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.123f5962c19cc984b71dd647fc6e608a@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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 improved the rules for writing `reverse` back to a recursive form. It appears to be good to fuse in most cases. The main exceptions seem to be `filter p . reverse` (although `reverse . filter p` is good) and `takeWhile . reverse` (although `reverse . takeWhile` is good). The latter was investigated by Dan Doel. The problem seems to be that the closures built up in the bad cases end up allocating more than the conses they replace. Even the worst case for `nofib` (a `filter . reverse` form) isn't really too terrible. I think we're probably better off making this change than not. Note: rules to try to convert `filter p . reverse` back to a (slightly) better version seem inherently too fragile to want to bother with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 30 23:16:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Aug 2014 23:16:19 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN Message-ID: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Easy (less than 1 | result at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I assume that this is well-known, but it tripped me up: {{{ Prelude> let inf = 1/0 Prelude> let nan = 0/0 Prelude> min nan inf Infinity Prelude> min inf nan NaN Prelude> min 3 nan NaN Prelude> min nan 3 3.0 Prelude> max nan inf NaN Prelude> max inf nan Infinity Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 07:22:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 07:22:53 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.afc23cbe22de643350b6b509cc96004d@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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): AT least for `filter p . reverse`, couldn?t you rewrite it to `reverse . filter p` if that is for whatever reason better? Seems to be a nice small optimization (though, like many of them, probably of little practical relevance.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 09:23:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 09:23:33 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.62c92442c9c140503245aa68afbf70f6@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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]: > AT least for `filter p . reverse`, couldn?t you rewrite it to `reverse . filter p` if that is for whatever reason better? Seems to be a nice small optimization (though, like many of them, probably of little practical relevance.) Unfortunately, that changes semantics. `filter (==1) (reverse [undefined,1,2]) = 1:undefined` but `reverse (filter (==1) [undefined,1,2]) = undefined` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 09:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 09:30:48 -0000 Subject: [GHC] #9531: Implement Prelude.Word Proposal Message-ID: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> #9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: Prelude | 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: -------------------------------------+------------------------------------- ''(this text is a placeholder and will be replaced shortly)'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 09:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 09:31:42 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.f99139865d6d10107f8332da269ff539@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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:9 dfeuer]: > Replying to [comment:8 nomeata]: > > AT least for `filter p . reverse`, couldn?t you rewrite it to `reverse . filter p` if that is for whatever reason better? Seems to be a nice small optimization (though, like many of them, probably of little practical relevance.) > > Unfortunately, that changes semantics. `filter (==1) (reverse [undefined,1,2]) = 1:undefined` but `reverse (filter (==1) [undefined,1,2]) = undefined` And to go along with that, as dolio mentioned to me, the performance may be worse if only part of the list is used and the filter predicate is expensive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 10:27:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 10:27:09 -0000 Subject: [GHC] #9531: Implement Prelude.Word Proposal In-Reply-To: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> References: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> Message-ID: <057.de5367e351ca57762a7f7fe35df6ca14@haskell.org> #9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Prelude 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 Herbert Valerio Riedel ): In [changeset:"393b820233caa00e428affc28e090b496d181664/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393b820233caa00e428affc28e090b496d181664" Re-export Word from Prelude (re #9531) The original proposal text can be found at http://www.haskell.org/pipermail/libraries/2014-August/023491.html The proposal passed with a clear majority, and was additionally confirmed by the core libraries committee. *Compatibility Note* Only code that imports `Data.Word` for the sole purpose of using `Word` *and* requires to be `-Werror`-clean (due to `-fwarn-unused-imports`) is affected by this change. In order to write warning-free forward/backward compatible against `base`, a variant of the following CPP-based snippet can be used: -- Starting with base>4.7.0 or GHC>7.8 Prelude re-exports 'Word' -- The following is needed, if 'Word' is the *only* entity needed from Data.Word #ifdef MIN_VERSION_base # if !MIN_VERSION_base(4,7,1) import Data.Word (Word) # endif -- no cabal_macros.h -- fallback to __GLASGOW_HASKELL__ #elif __GLASGOW_HASKELL__ < 709 import Data.Word (Word) #endif This also updates the haddock submodule in order to avoid a compile warning }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 10:30:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 10:30:39 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.7086b1b228c1fecfbb2c102804522adc@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): ... also signum NaN returns -1.0, rather than NaN -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 10:53:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 10:53:40 -0000 Subject: [GHC] #9523: Typo in GHC Generics documentation In-Reply-To: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> References: <045.f6500f2e6e7dfb47345436a2e3e2ff3d@haskell.org> Message-ID: <060.e6fd6478c4b07ecc39b93db1c656e7a7@haskell.org> #9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 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: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 12:02:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 12:02:57 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.5506b74b90e58f45714608c2548d5e43@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.9 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): Ok, sorry, didn?t think it through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 12:33:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 12:33:37 -0000 Subject: [GHC] #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface Message-ID: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9340 | Test Case: | Blocking: | Differential Revisions: Phab:D158 -------------------------------------+------------------------------------- GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way. This was proposed as http://www.haskell.org/pipermail/libraries/2014-August/023567.html and passed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 12:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 12:34:27 -0000 Subject: [GHC] #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface In-Reply-To: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> References: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> Message-ID: <057.056682d66d8c4afaefa59189d274f8da@haskell.org> #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Data.Bits Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9340 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D158 | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => Data.Bits * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 12:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 12:36:05 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.06f5c6ded47dd8f7578a17b1f7718e61@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz ctz (CodeGen) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9532 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D144 | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9532 Comment: See #9532 for the related `Data.Bits` CLZ/CTZ interface ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 14:28:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 14:28:00 -0000 Subject: [GHC] #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface In-Reply-To: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> References: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> Message-ID: <057.206a387db224ba7890e7af503ae75c86@haskell.org> #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Data.Bits Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9340 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D158 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a8a969ae7a05e408b29961d0a2ea621a16d73d3e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8a969ae7a05e408b29961d0a2ea621a16d73d3e" Add `FiniteBits(count{Leading,Trailing}Zeros)` This exposes the newly added CLZ/CTZ primops from e0c1767d0ea8d12e0a4badf43682a08784e379c6 (re #9340) via two new methods `countLeadingZeros` and `countTrailingZeros` in the `Data.Bits.FiniteBits` class. The original proposal can be found at http://www.haskell.org/pipermail/libraries/2014-August/023567.html Test Plan: successful validate Reviewers: ekmett, tibbe GHC Trac Issues: #9532 Differential Revision: https://phabricator.haskell.org/D158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 14:28:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 14:28:00 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.39bccff501cc17f0f8124164a6a0e626@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz ctz (CodeGen) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9532 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a8a969ae7a05e408b29961d0a2ea621a16d73d3e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8a969ae7a05e408b29961d0a2ea621a16d73d3e" Add `FiniteBits(count{Leading,Trailing}Zeros)` This exposes the newly added CLZ/CTZ primops from e0c1767d0ea8d12e0a4badf43682a08784e379c6 (re #9340) via two new methods `countLeadingZeros` and `countTrailingZeros` in the `Data.Bits.FiniteBits` class. The original proposal can be found at http://www.haskell.org/pipermail/libraries/2014-August/023567.html Test Plan: successful validate Reviewers: ekmett, tibbe GHC Trac Issues: #9532 Differential Revision: https://phabricator.haskell.org/D158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 15:09:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 15:09:06 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code Message-ID: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code outputs "A". {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of -1 -> "A" _ -> "B" main = putStrLn $ show test }}} However, adding a new case that isn't matched causes the output to change: {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of 5 -> "C" -1 -> "A" _ -> "B" main = putStrLn $ show test }}} With the extra '5 -> "C"' line in the case, the output is "B". It gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session: {{{ Prelude Main> :l *T.hs [1 of 1] Compiling Main ( T.hs, interpreted ) Ok, modules loaded: Main. *Main> main "A" *Main> :l T.hs Ok, modules loaded: Main. Prelude Main> main "B" Prelude Main> }}} These examples suggest to me at least 3 improvements: * Issue a warning when a negative number is used in a case statement in unsigned context * Interpreted code should give the same result as compiled code * Adding a case that isn't matched shouldn't change which other patterns get matched -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 15:28:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 15:28:29 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.97309c9115b1a8813f7b02794600bd5e@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: | Owner: MichaelBurge | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high * os: Windows => Unknown/Multiple Comment: Wow, nice catch. Something is wrong with the translation of STG-level `case` on `Word#` into Cmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 16:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 16:11:49 -0000 Subject: [GHC] #9531: Implement Prelude.Word Proposal In-Reply-To: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> References: <042.cd2d8918281e2e3dc04f053817312985@haskell.org> Message-ID: <057.045db1d31d265d0aafab6605216d65d5@haskell.org> #9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Prelude 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 hvr): * status: new => closed * resolution: => fixed Old description: > ''(this text is a placeholder and will be replaced shortly)'' New description: This was proposed on the libraries list and succeeded by vote majority as well as by explicit confirmation from the core libraries committee. See [http://www.haskell.org/pipermail/libraries/2014-August/023658.html proposal summary] for details. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 16:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 16:13:37 -0000 Subject: [GHC] #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface In-Reply-To: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> References: <042.f5f5d5287348b632b9971ccbf3356cd1@haskell.org> Message-ID: <057.21c91461db456984e18fa665fabdba7b@haskell.org> #9532: Expose new CLZ/CTZ primops via `Data.Bits` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Data.Bits Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9340 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D158 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Old description: > GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is > about exposing those in a more convenient way. > > This was proposed as > > http://www.haskell.org/pipermail/libraries/2014-August/023567.html > > and passed. New description: GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way. This was proposed as http://www.haskell.org/pipermail/libraries/2014-August/023567.html and passed (see also [http://www.haskell.org/pipermail/libraries/2014-August/023657.html proposal summary]) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 16:22:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 16:22:39 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.ed99db499e79eb56895e5e6d7ea5bad3@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: | Owner: MichaelBurge | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) 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): It's not specific to `Word#` actually. The following program has the same wrong behavior. {{{ x :: Int x = 11 y :: Int y = 10 test = case x - y of 3 -> "D" -- comment out either of these two lines and output will be "A" 5 -> "C" 18446744073709551617 -> "A" -- 2^64 + 1 _ -> "B" main = putStrLn $ show test }}} If I build ghc with `-DDEBUG` I get panics like {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140831 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Literal.lhs line 222 18446744073709551617 }}} so I suppose the error is really in creating these `Literal`s with out-of- range values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 17:31:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 17:31:37 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.64044903fbeba0df85f13bde540d59d6@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: | Owner: MichaelBurge | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) 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): Some more good stuff. {{{ test = case 1 :: Int of 18446744073709551617 -> "A" -- 2^64 + 1 _ -> "B" main = putStrLn $ show test }}} prints "B". The `KnownBranch` optimization fires (even without `-O`) and thinks that 1 is not 18446744073709551617. I'm inclined to conclude that Core `Literal`s should always be wrapped to the range of integers that their type can represent. I assume that `HsLit`s should hold the actual integer in the source program, though, so we can display expressions as the user wrote them. Simon, any thoughts? Also, there is no warning about the out-of-range literal patterns in any of these programs. Perhaps that ought to be a separate feature request ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 17:42:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 17:42:47 -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.25abe10eca109433eb8ee3b3d4542025@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: My testing indicates that for large lists (e.g., 10,000 elements), Bertram Felgenhauer's simple and mostly very clean `initsT'` implementation is much better than any variation on `initsQ` when concatenating the results. I wrapped it up in `build` to get a ''little'' fusion potential (not essential) and uploaded a patch. I would still like very much to understand why using `take'` gives slightly better performance than using `take`, but it very clearly does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 17:51:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 17:51: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.86be1d009fcbc339a217271e4aa9e56c@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | 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): If someone is able to do benchmark comparisons for lists of various sizes, that would really be great; I'm not currently able to use Criterion on GHC 7.9. It's possible that `initsQ` is better when the list is fairly small relative to the cache size and `initsT'` is better when it's large, in which case someone will have to make a judgement about which case is more important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 19:06:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 19:06:34 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.01e8b81051db0648e4ded685f944d7cd@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid * related: => 9276 * blockedby: => 9276 Comment: thanks for reporting that you found these behaviors confusing, because they are! (though they are totally kosher with respect to the IEEE Floating point semantics, as well as the Ord instance for floating point numbers, so technically not a bug, but rather a distasteful behavior). thus while it IS an unexpected behavior, its not a bug ( try doing `[1.07 :: Float .. 9.9]`in ghci to see something truly bonkers that ), Its worth noting that the ieee standard specifies an even worse behavior for min and max, that when only one arg is NAN, return the *other* (not NAN) argument! (though the historical motivation is a bit suspect.) In fact, i've been working on writing up a proposal to change the semantics of min and max on floating point values! (should happen some time after ICFP is over this week). I spoke with a number of the Julia lang folks about this issue (which was raised with them after I discussed min/max with a member of their community), and I'll likely propose to change the floating point min / max to have the same semantics as their change https://github.com/JuliaLang/julia/issues/7866 their change is: 1) when either argument of min/max is NAN, return NAN 2) Except: a) for min, when either argument is -\infinity, return - \infinity b) for max, when either argument is +\infinity, return +\infinity that said, i'm letting the design / thinking about the implications bake before writing up a proposal that change (though it seems like the most reasonable possible definition given the constraints of Float and Double), because getting the semantics as right as possible matters, and id like to be confident in changing how math works for haskell before committing to the change. I do think that this change in definition will get unanimous support, but i'm trying to also understand *WHAT* else can be fixed up in the same proposal that should be included along with that change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 19:16:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 19:16:30 -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.2424dafcf46c38bd939c6b64df9c1e01@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | 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?m really worryied seeing `INLINE` on such a rather large function. Doesn?t that mean that we will never use the compiled `inits` from the library but rather re-compile it at every use site? That does not seem to be good. (Disclaimer: Have not actually tried it.) I have run criterion on HEAD earlier, I might be able to set it up again. Do you have a ready-to-run benchmark that you would like me to run? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 19:21:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 19:21:01 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.d16de35e34f779ee0d0e5009bf473cbd@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 carter]: > thanks for reporting that you found these behaviors confusing, because they are! > (though they are totally kosher with respect to the IEEE Floating point semantics, as well as the Ord instance for floating point numbers, so technically not a bug, but rather a distasteful behavior). > > thus while it IS an unexpected behavior, its not a bug ( try doing `[1.07 :: Float .. 9.9]`in ghci to see something truly bonkers that ), > > Its worth noting that the ieee standard specifies an even worse behavior for min and max, that when only one arg is NAN, return the *other* (not NAN) argument! (though the historical motivation is a bit suspect.) > > In fact, i've been working on writing up a proposal to change the semantics of min and max on floating point values! > (should happen some time after ICFP is over this week). I spoke with a number of the Julia lang folks about this issue (which was raised with them after I discussed min/max with a member of their community), and I'll likely propose to change the floating point min / max to have the same semantics as their change https://github.com/JuliaLang/julia/issues/7866 > > their change is: > 1) when either argument of min/max is NAN, return NAN > 2) Except: > a) for min, when either argument is -\infinity, return - \infinity > b) for max, when either argument is +\infinity, return +\infinity > > that said, i'm letting the design / thinking about the implications bake before writing up a proposal that change (though it seems like the most reasonable possible definition given the constraints of Float and Double), because getting the semantics as right as possible matters, and id like to be confident in changing how math works for haskell before committing to the change. > > I do think that this change in definition will get unanimous support, but i'm trying to also understand *WHAT* else can be fixed up in the same proposal that should be included along with that change. I think it probably makes sense to have multiple sets of operations available: 1. IEEE compliant stuff, whether sane or not. 2. Stuff that's fast in hardware, whether sane or not. 3. Stuff that's sane. Your \pm\infty thing only makes a sort of sense for some NaN situations, I believe. I can buy `max (1/0) (0/0) = Infinity`, for example, but it's hard for me to make sense of `max (1/0) (sqrt (-1))` being anything but NaN. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 19:33:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 19:33:00 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.c1db3edc7aaa74d0d05cef277162eca6@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): the ieee min/max behavior on nans is bonkers and useless for us. @dfeuer happy to chat about this more via irc or email, but Floats aren't numbers, they just act like they are, but explaining their semantics in more detail and why/when ieee should be ignored or not is too complicated for trac tickets -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 19:35:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 19:35:04 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.46d732b5a5c6301a489071f98dd61e8e@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): most of the IEEE operations that have hardware support baked in are pretty reasonable and what ghc already does. min/max is one of the few operations where the ieee spec, the hardware supported spec, and the reasonable semantics specs are not the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 20:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 20:14:48 -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.8f1450b7f91a62416e9ae8d23e189890@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | 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:18 nomeata]: > I?m really worryied seeing `INLINE` on such a rather large function. Doesn?t that mean that we will never use the compiled `inits` from the library but rather re-compile it at every use site? That does not seem to be good. (Disclaimer: Have not actually tried it.) > > I have run criterion on HEAD earlier, I might be able to set it up again. Do you have a ready-to-run benchmark that you would like me to run? I think we can just skip the `build` and get rid of `INLINE` without any significant harm. The fusion potential with this definition is quite limited anyway. The most interesting-looking fusion opportunities (not enabled by that definition anyway) seem to be `inits/enumFromTo` and `concat/inits`. The former is great if things are, and remain, unboxed, and horrible otherwise, and we can't tell the difference, unfortunately. The latter might be worth thinking about, if anyone actually writes that. This looks very good in Core, if we can find a way to accomplish it: {{{#!hs concat (inits xs) = build (\cons nil -> let go _ _ [] = nil go n k (y:ys) | n == k = go (n+1) 0 xs | otherwise = y `cons` go n (k+1) ys in go 1 0 xs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 21:18:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 21:18:07 -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.3449e06dd084ed57d07f0bc595cf36b9@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | 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 attached a new patch without the `build` or inlining, and upgrading from `Int` to `Word` to double the number of lists we can pull from `inits . cycle` before the world explodes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 22:08:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 22:08:42 -0000 Subject: [GHC] #9530: min / max do not always return a NaN when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.2342bdd7202e1dd5654a8cd01a0283c6@haskell.org> #9530: min / max do not always return a NaN when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): I don't have a copy of the standard, but http://en.wikipedia.org/wiki/IEEE_754_revision says {{{ min(x,NaN) = min(NaN,x) = x max(x,NaN) = max(NaN,x) = x }}} which is not satisfied here {{{ Prelude> max 3 nan 3.0 Prelude> max nan 3 NaN }}} http://msdn.microsoft.com/en- gb/library/windows/desktop/jj218760(v=vs.85).aspx agrees: {{{ The IEEE-754R specification for floating point min and max operations states that if one of the inputs to min or max is a quiet QNaN value, the result of the operation is the other parameter. }}} It goes on to add a further wrinkle: {{{ A revision of the IEEE-754R specification adopted a different behavior for min and max when one input is a "signaling" SNaN value versus a QNaN value: }}} So far as I can tell, Haskell does not know anything about signalling NaNs, so this is probably not applicable. I'll change the title of the ticket to make the issue clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 22:10:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 22:10:02 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN (was: min / max do not always return a NaN when one of the arguments is NaN) In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.37e17c4c4265307a79aada5a2a0c27b3@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jrp): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 22:13:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 22:13:34 -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.3ded58b5c7cb9db13626a02461632c9c@haskell.org> #9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch 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): * status: new => patch Comment: Effects are generally small, but it seems to do a bit of good. The weakness is the `let`, of course. I'm still not sure we're gaining anything by trying to make this a good producer. Certainly making it a good consumer is good. I'm going to do a bit more hacking and testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 22:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 22:53:04 -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.b40f2eec4c9d004f776ca2a0072d2147@haskell.org> #9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch 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 dfeuer): It looks like strictness analysis can work its magic in nice cases and unbox the accumulator, erasing the let. I think this is probably good to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:02:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:02:42 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.37cf0710b3f05b83e7521ce07f4cab18@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @jrp, in this case the IEEE standard doesn't make sense to comply with, if you read that julia lang ticket about the min/max behavior, theres an inline email by one of the IEEE spec authors about the motivation for the nan evading behavior. though I do agree from a strict IEEE compliant behavior standpoint, it is nonconforming, this is a very clear example (perhaps the ONLY example) where min/max are better off being implemented in a different way. Haskell has no need for using Nan to pun representing missing data. (see that julia lang thread for a longer discussion on the matter) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:05:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:05:30 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.dabb3afe5ff2c10af80934f285c01c95@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): (though if theres a good argument to the contrary, please share! :) ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:07:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:07:02 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.ce2e8a50d45d4f902f6f676b17821b3d@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): oh, and http://www.wellposed.com/standards-documents- cache/IEEE%20754%202008%20floating%20point%20standard%20fpstandard-2008.pdf is copy of the ieee spec i keep handy :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:18:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:18:11 -0000 Subject: [GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB Message-ID: <042.b57925db7a33a6c9734a74f56439475b@haskell.org> #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: IEEE754 | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Incorrect than a day) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached is an implementation of the floating point accuracy test described in ''The Baleful Influence of Benchmarks'' section of http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF {{{ Results for Float: r = 4098.0 produces 12.0 and 12.0 sig. bits r = 4098.25 fails: root 0.99989897 isn't at least 1 <<<< r = 4097.004 produces 12.0 and 11.999298 sig. bits : Worst accuracy is 11.999298 sig. bits : Results for Double: r = 4098.0 produces Infinity and Infinity sig. bits r = 4098.25 produces Infinity and 53.0 sig. bits r = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits r = 1.6777218e7 produces Infinity and Infinity sig. bits r = 1.677721825e7 produces Infinity and 75.0 sig. bits r = 1.6777219e7 produces Infinity and 71.0 sig. bits r = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits r = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<< r = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits r = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits r = 2.68435458e8 produces 28.0 and 28.0 sig. bits r = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits r = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits r = 4.294967298e9 produces 32.0 and 32.0 sig. bits r = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits Worst accuracy is 26.499999986733027 sig. bits }}} This seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997). '''The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.''' Observations: * There are a couple of failures (could be the implementation of sqrt or log). * signum seems incorrect (signum Nan = -1.0) * The prelude should have a copysign function * min fails to produce the other argument if one argument is NaN * The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions * The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic * There may be a better way of entering the test values of r to ensure that they are accurate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:26:04 -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.022ac31c3cc17757ef186d44ff1a0ad7@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): Replying to [comment:2 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.: SNIP > But I don?t expect there to be a measurable difference (and I didn?t check): I brilliantly read your code wrong and drew a bad conclusion. This looks much better than I initially thought (Look, ma, no `let`! ). I'm going to see how nofib likes it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 31 23:46:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Aug 2014 23:46:28 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.42e06284907e5fb743461410744fad87@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: | Blocked By: 9276 Blocking: | Related Tickets: 9276 Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): Thanks. I'll have a more detailed look. I can't, however, see any good reason for having min / max asymmetrical in their arguments, whether the result is to be NaN or the other argument. The standard seems to agree. It says (at 5.3.1) that '''''minNum(x, y) is''' the canonicalized number x if x GHC The Glasgow Haskell Compiler